On 3 August 2010 10:12, Aleksei Valikov <valikov_at_gmx.net> wrote:
> Hi,
>
>>> Recently I did some experiments. I can imagine a JAXB 2 plugin which
>>> analyzes the schema and generates JSR 303 annotations which describe
>>> how the bean must be validated. In this case bean validator may report
>>> XML Schema validation errors with locations in the object structure.
>>
>> In what way would that be better than the XML schema based
>> validation?
>
> If you work with objects in first place then information "your object
> is missing the required [name]" property" is more valuable than
> "required attribute @name is missing in the element foo". It is
> important to know "where" an "what" applied to objects, not to XML.
> If you're XML centric then emphasis is different, schema-based
> validation of XML is more important.
>
Both get the job done, but I see that different "categories" of
error message readers might prefer this or that.
>
> However one thing must clear from the theory point of view. If you can
> use an XML Schema in runtime to validate XML then it must also be
> possible to express the same constraints on the class level
> (validation annotations) to validate object structure corresponding to
> that XML. It may be hard but it is possible.
Certainly. - Schema facets are comparatively simple. Given a
customizing mechanism for adding such annotations, it should
not be unsurmountable to derive the required <bindings>
from the schema. I recently did some XSLT programming on
XML schemas, so I do know where the difficulties are ;-)
>
>> Recently I investigated the application of rule based programming
>> for this task, which is quite satisfying as it permits the definition of
>> the validation rules in a way that's akin to domain expert language.
>> And there's practically no limit to the complexity of validation rules.
>
> You can always add custom validation annotations, I don't see any
> constraints here. JSR 303 is a very sensible thing.
Doing all in one place has a certain charm, though.
But all of these validations that are performed on a programmatically
built object tree or the XML document created from that have the
disadvantage that they won't tell you the place where the bad data
was injected originally. For this, checks must be made at setter-call time.
-W