On 11/20/2010 04:15 AM, Archie Cobbs wrote:
>
> On Thu, Nov 18, 2010 at 8:37 PM, Dennis Sosnoski <d...@sosnoski.com
> <mailto:d...@sosnoski.com>> wrote:
>
> The issue with "flexible" unmarshalling is that JiBX normally
> generates code based on the expected order of elements in order to
> get the most efficient processing - at any point in the
> unmarshalling it can just check for the next expected element, and
> if it's not found skip to the following one, an approach that
> works very well with a pull parser. So-called "flexible"
> unmarshalling instead requires that it look at the element name
> and then fan-out for processing based on that name.
>
> For 2.0 I'm planning better handling of this case, but it's always
> going to be somewhat ugly.
>
>
> I'll take your word for it... but I'm still curious about this (pardon
> my ignorance). If this is too complicated to explain just say so and
> I'll stop asking :-)
>
> The difficulty seems backwards. It seems that supporting
> flexible="true" should actually be easier in the ordered="true" case
> than in the ordered="false" case. In the ordered="true" case, if you
> see something other than the next expected element, you just skip it
> and go on to the next one (as you described above). It seems like only
> in the ordered="false" case do you need to do any kind of lookup
> operation...
>
> Ah, perhaps you're requiring the parser to distinguish between an
> unknown element and an out-of-order element? Then a lookup would be
> required. But a lookup is required in the ordered="false" case, so we
> already know how to do that... ?
With ordered='false' you can just have a bag of elements and accept any
one of them at any time, basically doing a switch statement on the
element name to handle it. This is what JAXB and .Net do by default -
which means they deliberately ignore the ordering of elements in the
schema, helping to create interoperability problems with tools that *do*
look at schema ordering.
What makes flexible='true' combined with ordered='true' more complex is
the need to support optional elements. At any point in the parse, the
next element in the input may be the next element in your schema
sequence, or *any following element up to and including the first
required element*, or any other element (which should be ignored).
Probably the best way to handle this in code is to use a state index for
the elements in the sequence (state 'n' meaning we've parsed the first
'n' elements in the sequence), and again use a switch statement on the
element name but this time combine it with some state logic (to assure
that the known elements are in order, and that required ones aren't
skipped). But then what do you do with the same element name used more
than once at different points in the sequence?
So like I said, it's ugly. :-)
- Dennis
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
jibx-users mailing list
jibx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jibx-users
