Defining additional validation rules in XSD schemas

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Defining additional validation rules in XSD schemas


Following the discussion we had in EBM WS this morning, I'm starting this topic to make the things move forward.

Little summary:
The PEtALS plug-ins generate the component and the CDK specific parts from XSD files.
Which means that in the wizards, the pages relative to the component and to the CDK are generated from XSD files and sometimes completed by hand.
The generation covers the widgets (or GUI), the validation of the user input, and the writing of these elements in the created jbi.xml file.

The problem:
The current mechanism we use is hand-made and incomplete.
It sometimes requires the plug-in developer to add additional widgets (but this not a problem we want to address here) and extra-validation (this is the problem).
XML schemas is an imperfect way to describe all the constraints we would want to check on an XML file.
It is good for the structure part, but not for the content-relative part.

If this mark-up has this value, then I want to make sure that this other mark-up does not have a greater value.

The solutions we have:
  • Write extra-validation in Java, in some class.
    Pros: everyone knows Java.
    Cons: requires to simplify the manipulated objects (write light code) => API.
  • Add annotations in XSD files.
    Pros: everything is in the XSDs.
    Cons: choose a syntax, find a processor.
  • Change the model. Do not use XSDs anymore.
    Pros: change for a better solution.
    Cons: choose a model, something standard if possible, and find a processor.
  • Any other suggestion?

I found this interesting link :
It gives some examples.

I'd like to get some feedback about this from those who are likely to develop their own plug-ins in a not-yet-determined future.
Because the only interest for using XSD files and generating most of the wizard content is to have plug-ins developers who are not familiar with Eclipse.
As a reminder, at the beginning, this generation-based solution was chosen in order to see every PEtALS component developer make the associated Eclipse plug-in.
In any case, any solution will require the component developer to provide extra-artifacts:
  • XSD annotations
  • XSL files
  • Java annotations
  • Any other validation rules

The XSD model should be kept in any case.
It could also be used for the edition part (with XEF).
The question is just how we can define extra-contraints. And what is the frequence of such definitions?

-------------------- m2f --------------------

Read this forum topic online here:

-------------------- m2f --------------------

Users mailing list
[hidden email]