Falk Langhammer wrote:
Dennis Sosnoski wrote: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 and parseToStartTag).
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.
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
-- Dennis M. Sosnoski Enterprise Java, XML, and Web Services Training and Consulting http://www.sosnoski.com Redmond, WA 425.885.7197
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
jibx-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jibx-users
