Aleksei Valikov wrote:
> One of the questions is how to compile datatype checks. The only idea I
> have is to create an inner string field and serialized datatype
> available at the generation time into this field. In the runtime,
> datatype will be deserialized and used to perform the check. This is a
> bit awkward, I'd say but I don't have a better idea right now.
Yes. This is a nasty problem.
>
> The second question is about "repeatable elements". For instance,
>
> <xs:element name="book" type="bookType" minOccurs="3"
> maxOccurs="unbounded"/>
>
> Woulc be represented in the grammar as something like:
>
> sequence(sequence(book, book), oneOrMore(book))
>
> There's a marker expression OccurenceExp, but generally these cases
> should be handled without this marker. The problem with this expression
> is that it cannot be processed on the field item level since we'll loose
> the semantics of a collection.
> The solution I see is to first simplify the expression tree replacing
> expressions like sequence(fieldItem, epsilon), sequence(fieldItem,
> fieldItem), oneOrMore(fieldItem) with fieldItems with appropriate
> multiplicity. After this simplification we should receive an expression
> tree where leaves are fieldItems with correct multiplicity and inner
> nodes are sequences, choices and so on. This would be something similar
> to RelationNormalizer of XJC, but it won't produce class items, just
> simplify the tree.
In a general case, you really need to run a state machine, for sometimes
it is possible for a property to contain items of different kind (try a
mixed complex type with some elaborated content model.) These general
cases are very hard.
In my experience with interacting users, they don't usually have
compliated structured constraints (such as "only three As, no more, no
less"), and they seem to be more interested in getting the datatype
validated properly.
So I think you might want to concentrate on the datatype validation
aspect first.
> I am sorry that my thoughts may seem a bit vague. I'm enthusiastic about
> what I'm doing, but don't have a structured comprehension of that. :)
>
> I'd be also gratefult for your feedback.
>
> Bye.
> /lexi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>
>
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
For additional commands, e-mail: users-help_at_jaxb.dev.java.net