The serializer should support differents kind of XML protocol, and should facilitate the implementation of a new one. It is the reponsability of XSLT processor to send events (whatever the protocol) in the correct order.
I agree that it's more a xerces task. Is there any plans to implement a separate serializing component there?
Lionel Villard
IBM Research
| Joseph Kesselman/Watson/[EMAIL PROTECTED]
08/01/2003 11:23 AM
|
To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: Re: XSLT/XQuery serialization: toward a separate implementation |
Off-the-cuff reaction, not thought through:
What would you be serializing from? SAX? A customized superset of SAX
(which is what we've been using, since XSLT doesn't necessarily generate
results in the order SAX assumes)? An even more customized
event-stream/calling-sequence (which is where we may be going for
performance reasons)?
The farther we push the performance envelope, the less likely that this
will be a truly separable component. And I'm not convinced that's a bad
thing.
Truly modular serialization strikes me as more a Xerces kind of task than a
Xalan task, except in the special case of running TrAX in
identity-transformation mode.
______________________________________
Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more.
"The world changed profoundly and unpredictably the day Tim Berners Lee
got bitten by a radioactive spider." -- Rafe Culpin, in r.m.filk
