[BXXPwg] Draft Minutes of last week's meeting
10 Aug 2000 09:06:10 -0700
Greg Hudson <ghudson@MIT.EDU> writes:
> 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.
One idea I've been kicking around that seems tenable is to say that a
<start>/<profile> element's content model is #PCDATA, rather than
ANY. Think about that before you dismiss it. You could easily collect
and pass this delimited string onto any profile as a simple character
string. It's opaque to Channel 0. For all we know, it's Base64-encoded
data, or - (duck) - escaped XML that can subsequently parsed by a
suitably-interested profile handler.
Consider an example:
The profile would then get handed an "initialization string" of
which the profile handler could then feed into expat or any other
parser that can read input from an in-memory buffer.
What's the trade-off? The <profile> text must be XML-escaped before
being sent and it isn't checked for "well-formedness" by the Channel 0
parsing pass. But, arguably, it shouldn't be checked, because maybe,
for some profiles, it's not supposed to be XML!
This would make for an easier channel creation API and impose less
burden on profiles that are not interested in XML. You've already (sort
of) used this approach with the <blob> element in the SASL
profiles. It seems that you could simplify so much be adopting a
similar idea here.
Steven E. Harris :: sharris @primus.com
Primus :: http://www.primus.com