[standards-jig] No Subject....

Casey Crabb debug at nafai.dyndns.org
Fri Feb 1 22:18:06 UTC 2002

On Fri, 2002-02-01 at 16:59, Iain Shigeoka wrote:
> On 2/1/02 1:10 PM, "David Waite" <mass at akuma.org> wrote:
> > 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.
> Doh.  Yeah.  I should have been clearer.  Within a frame, we must assume a
> complete XML document.  So any malformed data within the framed document
> will cause the whole document to be invalid... However in this case, just
> the frame not the entire session.  The current Jabber scheme embeds the
> entire session within a <stream> so any error anywhere should cause a bail
> out.  In fact, doesn't that mean that from a strictness standpoint, if we do
> a bailout in the middle of a jabber session we should "undo" the effects of
> the session... :)

Just a quick comment:
If I understand correctly you want each frame to be a complete xml
document-like-thing (so that a valid frame would parse by itself in a
xml parser). If what I'm hearing is correct, then we need a new XML
parser for each frame. Creating this parser can be very expense to the
point that it would negate the bonus from the framing.
If I'm misunderstanding just ignore me :)

More information about the Standards mailing list