Hi.
> i'd be interested in learning more. is there some source going yet?
I've requested a new project on dev.java.net. While it is being
processed, you may take a look at the current build:
http://herakles.fzi.de/lexi/jaxb-verification/jaxb-verification.zip
Run de.fzi.dbs.verification.addon.tests.AddOnTest unit test in the
tests\books directory.
I feel like it's the right direction - the code which is already
generated is quite close to what I personally need.
The tool should report the following problems:
1. Data problem - bad data like string not matching regexp, number out
of specified bounds etc. Master object, field name, wrong value are
reported.
2. Structural problems.
2.1. Missing object - if the field should not be empty while it is.
Master object and field name are reported.
2.2. Existing object - if the field should be empty (for instance, in A
| B when A exists B should not exist). Master object, field name, field
value are reported.
2.3. Wrong count of elements in a collection property (might be a
subclass of one 2.1 or 2.2). Master object, field name, current count,
minOccurs, maxoccurs are reported.
... and so on.
My experiments show that it's quite possible (and not that complex as I
thought before) to implement such a tool. I've got a couple of questions
open but I think they can be solved.
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.
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.
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