Falk Langhammer wrote:
>Dennis Sosnoski wrote:
>>It's not as simple as it might appear, Falk. The issue is that JiBX
>>makes use of element ordering in combination with a pull parser to
>>improve unmarshalling performance. Because of this, JiBX always wants to
>>know what to expect next.
>ok, I see why its not supported yet.
>However, there may be a chance that You only THINK its not trivial while there
>still is a trivial solution to it (at least in the unordered/optional cases).
>Lets call the mode JiBX would need 'relaxed' and lets assume that 'relaxed'
>implies 'unordered' or 'optional'.
>JiBX already certainly IS able to skip above unknown elements when encountered
>as childs of an unmapped element (the empty <structure/>). This skipping does
>probably happen inside the pull parser.
That's actually where the problem lies - JiBX adds
marshalling/unmarshalling code within the actual bound classes (or in
helper classes) that drives the whole process. For unmarshalling this
code asks for values in sequence, by name. Depending on the type of
element value being unmarshalled, there are a dozen or so different
methods of the unmarshalling context that get called (parseElementXXX in
org.jibx.runtime.impl.UnmarshallingContext, along with parsePastStartTag
One alternative would be to just add new variations of all those methods
which would skip elements that don't match what's expected next, then
use these variations when a 'relaxed' binding is being compiled. Another
approach would be to implement this behavior as a separate variation of
the marshalling/unmarshalling context, which is what I'd talked about in
my last email.
There are some deeper problems, though. The biggie is optional elements
- if you expect a sequence of elements A, (B), C, where B is optional,
it's easy to handle either the sequence A, X, B, C or A, X, C properly
as input, but hard to do both. The problem is that when we see the
element X in one of these sequences we don't know whether to continue
looking for B or expect C next. Of course, it'd be fairly easy to handle
this case by just looking for either B or C - but then if you've got
multiple optional elements in a row the problem just keeps growing.
Probably the best I might be able to do, at least for the 1.0 release,
is to provide a relaxed mode that skips unknown elements that precede a
required element. Longer term I may need to look into better ways of
handling unordered sets of elements where unknown/unused elements could
be part of the mix. That's not too terribly difficult to handle -
basically just use a hashmap-like structure to map element names to
index numbers, then a switch statement equivalent to actually process
the known elements. But actually writing the code generation to handle
this is something I probably won't want to mess with for 1.0.
I've copied the dev list on this, since the discussion has moved into
technical implementation issues. If you want to follow up further please
respond only on the dev list.
Dennis M. Sosnoski
Enterprise Java, XML, and Web Services
Training and Consulting
Redmond, WA 425.885.7197