[BXXPwg] Draft Minutes of last week's meeting

Greg Hudson ghudson@MIT.EDU
Thu, 10 Aug 2000 10:07:38 -0400

I wrote:
> I agree.  But nested XML piggybaks don't help non-XML-using profiles,
> and if nested XML for this purpose doesn't sit well with current XML
> implementations, it seems to partially defeat the purpose of using XML
> in BEEP.

Marshall responded:
> i think there are at least 5 existence proofs of code written by
> different people that nested XML isn't a problem.

You appear to have generalized my statement beyond its stated meaning,
eliding the "for this purpose" clause, although I can't be certain.

Let's say I am a BEEP library and I receive a request on channel 0 and
begin parsing it with expat.  expat begins firing off handlers for the
elements in the XML and I quickly discover that it is a start element.
Soon, I get to the content of a profile element; this contains an XML
element I want to pass to the application.  I'm still in the middle of
an expat parsing run; how do I do this?  None of the alternatives seem
too great:

	* I could specify my library so that it takes responsibility
	  for my application's XML parsing, and invoke my
	  application's handlers from my own handlers.  This approach
	  is fairly elegant but rather constraining to my library's
	  interface; I imagine most library writers would want to pass
	  frames and piggyback data to the application as raw bytes.
	  (In particular, the application code may already have been
	  written to use its own XML parser.)

	* I could repackage the XML data as text as I receive it in
	  handlers, but that would mangle it and is pretty much a

	* I could call XML_GetCurrentByteIndex() when my handler
	  reaches the beginning and end of the nested XML, use
	  those to grab the nested XML out of the frame, and then
	  simply ignore the nested XML content in my own parsing run.
	  I'm not sure whether this approach is feasible (due to edge
	  cases); it certainly doesn't seem like something you want to
	  have to do during XML parsing.  And, of course, if you have
	  N layers of nested XML handled this way, you get O(N^2)
	  parsing work.

I'm willing to believe there is a good approach to this problem; I'm
not an experienced XML programmer.  I'm mostly relying on Steve
Harris's assertion that it doesn't work well, and he could be wrong
too.  But, even if so, the piggyback approach still doesn't help
non-XML-using profiles, as I mentioned before.  Since I hate RTT
penalties at least much as anyone else, I think it would be good to
have a mechanism which avoids the penalties for all kinds of profiles.