[standards-jig] No Subject....
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
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
>>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
I don't quite understand :-) Could you ellaborate?
More information about the Standards