[
Lists Home |
Date Index |
Thread Index
]
Rich Salz wrote:
>
> If the ASN.1 attaches an arbitrary order to an xs:all, then it's
> possible that it might receive XML in the exact opposite
> order that is
> in the ASN.1. Or do I misunderstand? If not, then you must
> be prepared
> to buffer the entire incoming xs:all content.
I think that I now understand what you mean.
It depends on how the software is written. Many decoders always buffer
everything anyway, as they parse and decode the message into a generated
class/structure in the target programming language. In this case, a
representation of the decoded abstract value is made available to the
application only at the end of the decode operation. So buffering is not an
issue for "all" more than it is for "sequence" - it always happens.
On the other hand, if you have a decoder that wants to present to the
application (e.g., via some callback mechanism) each component of the value
as soon as it is available, then yes, "all" forces the decoder to postpone
the callbacks until the end-tag of the parent element has been reached. A
decoder of this type would need to do some buffering for "all" that it
wouldn't need to do for "sequence".
Alessandro
> (Okay, I suppose you
> could convert to native form and just buffer that, but the
> point still
> holds.)
>
> I'm not saying this is *bad,* I'm just trying to understand all the
> nooks and crannies.
> /r$
|
