[standards-jig] No Subject....

David Waite mass at akuma.org
Fri Feb 1 21:10:41 UTC 2002


Iain Shigeoka wrote:

>On 1/30/02 3:21 PM, "mlin at mlin.net" <mlin at mlin.net> wrote:
>
>>ML: The purpose of byte length framing is not to entirely remove all XML
>>parsing. Well-formedness checking is easier than building a DOM. Furthermore,
>>byte length framing allows well-formedness checking to be done separately from
>>I/O, in another thread or on another CPU.  Thus, I'll agree that
>>well-formedness checking is necessary on all nodes, which is not stated in the
>>JEP; however, there are still performance benefits to be gained, and there are
>>further code simplicity advantages...
>>
>
>I disagree.  If we can isolate errors to frames, the behavior of error
>response (esp to malformed XML) can be changed dramatically.  Errors within
>a frame don't need to invalidate the session as they do now.  I also don't
>like the implication that the server will still need to parse the XML in a
>frame.  I don't think this is necessarily true if the framing is designed
>properly.
>
However, if you change the behavior of malformed data you then are no 
longer compliant with XML; the spec states that parsing should not 
continue on any fatal error (except for guessing further errors within a 
document). I suppose it would be possible for hops to indicate whether 
they have a custom XML parser, and have the sending entity parse and 
verify all the XML before routing on to these nodes. If a packet is 
invalid, it does not forward that chunk on.

I suppose what I'm really troubled by is that this resembles just extra 
CDATA in the XML, but support indicates that you can no longer use a 
compliant XML parser - you have to use a parser that understands the 
framing and will ignore a section if it does not pass additional tests. 
I suppose if it was more explicit that this was framing to be considered 
external to the data stream, it would make more sense to me. You just 
can't really have an 'optional' framing mechanism, because older clients 
and servers would not know the framing rules and how to recognize and 
handle invalid data.

>>DW: So, at some point later in the route, this non-well-formed data may hit a
>>node which does not support framing, and instead uses a normal XML parser.
>>This parser will stop parsing on the error. So, I could frame invalid packets
>>and send them over the wire to disrupt any clients or components using a
>>compliant XML parser. Because of this, client and server connections cannot
>>be trusted to provide well-formed XML, and the XML must be fully parsed
>>whether
>>or not framing information is present.
>>
>>ML: ...the critical difference is that it is much easier to fully parse the
>>packet with framing data available.
>>
>
>Agreed.  It especially makes XML data binding practical which can really
>accelerate things.
>
I don't quite understand :-) Could you ellaborate?

<snip>

-David Waite





More information about the Standards mailing list