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).
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.
Dennis,
with 'unordered' elements (order="false") You probably already use such variations, don't You? Why not treat 'relaxed' as subcase of unordered (give unordered unmarshalling code a flag)?
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
Even in a situation where You have ordered optional elements, You have a list of candidates for the next element. Just add a "*"-candidate to this list...
You actually have the bigger problem where both A, (D), (B), C and A, (B), (D), C are allowed with optional B and D: Do you continue to look for B after seeing D? JiBX can handle this now. An unexpected element 'X' to be ignored is simpler actually.
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.
I do not know what happens in JiBX internally with unordered elements. This seems to be more difficult anyway. If I were to write this, I would probably carry a Map of allowed possible tag names. (In case I have a list of unordered but not optional elements, I would keep a 'seen'-counter within the map -- note that JiBX requires 'optional' elements to avoid this situation.)
Again: An unexpected element is easier to handle (just continue).
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
Better don't. There may be many people reporting errors if content is appended (which is typical in a "required goes first" format).
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.
Fair.
I am just curious to know how You now do handle unordered elements if not with a map or list of candidates.
BTW. If You look into ways to improve JiBX and to reach new territory...
All frameworks consider Java<->XML as an equivalence mapping. There are many cases however, where You only want to process part of the information contained in an XML document within Java, and to only bind this part.
This not only means that unmarshalling must be relaxed (we discussed this in this mail thread), but also that marshalling must support insertion into an existing XML document (mix-in). Our XOperator already supports this at the XML level (to mix-in sub-documents into a larger one with similiarity mapping) which is why we can use JiBX at all.
Actually, this should be feasible (with a DOM tree at least). While marshalling, do a synchronized "unmarshalling walk" in the existing tree and 'override or create' the corresponding marshalled nodes. Collections would shrink or grow as well where an existing fraction would be overridden rather than deleted and recreated. Algorithmically, we know how to do such things. We just don't know where to insert this into JiBX.
It is really unfortunate that entire XML schemas must be mapped to do anything useful in Java with them. JiBX with its Java-centric approach would be best positioned to heal this.
Keep up the great work, Falk -- Dr. Falk Langhammer Living Pages Research GmbH Kolosseumstr. 1a D-80469 Munich, Germany mailto:[EMAIL PROTECTED] http://www.living-pages.de
-------------------------------------------------------
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-devs mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jibx-devs
