You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Lionel Villard <vi...@us.ibm.com> on 2003/08/01 17:03:20 UTC
XSLT/XQuery serialization: toward a separate implementation
Hi all,
with the forthcoming W3C recommendation for XSLT 2.0 and XQuery
1.0 serialization, it'd be great whether we can provide a separate
implementation from the xslt processing. I think it should not be so hard
and long to cut dependencies with Xalan in the org.apache.xalan.serialize
package. What do you think? Should we also provide an other package name,
like org.apache.xquery.serialization (xquery because the serialization may
belong to the data model of xpath/xquery and xslt relies on this
datamodel) ?
Thanks!
Lionel Villard
IBM Research
Re: XSLT/XQuery serialization: toward a separate implementation
Posted by sc...@us.ibm.com.
I think it's a good idea. I also think you should float this up to the
general list. -scott
Lionel Villard <vi...@us.ibm.com> wrote on 08/01/2003 11:03:20 AM:
>
> Hi all,
> with the forthcoming W3C recommendation for XSLT 2.0 and
> XQuery 1.0 serialization, it'd be great whether we can provide a
> separate implementation from the xslt processing. I think it should
> not be so hard and long to cut dependencies with Xalan in the org.
> apache.xalan.serialize package. What do you think? Should we also
> provide an other package name, like org.apache.xquery.serialization
> (xquery because the serialization may belong to the data model of
> xpath/xquery and xslt relies on this datamodel) ?
>
> Thanks!
> Lionel Villard
> IBM Research
Re: XSLT/XQuery serialization: toward a separate implementation
Posted by sc...@us.ibm.com.
> 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.
I really think it should be it's own thing. It's certainly not parser
technology.
-scott
Joseph Kesselman <ke...@us.ibm.com> wrote on 08/01/2003 11:23:17 AM:
>
>
>
>
> 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
>
Re: XSLT/XQuery serialization: toward a separate implementation
Posted by Lionel Villard <vi...@us.ibm.com>.
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/IBM@IBMUS
08/01/2003 11:23 AM
Please respond to xalan-dev
To: xalan-dev@xml.apache.org
cc: xalan-dev@xml.apache.org
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
Re: XSLT/XQuery serialization: toward a separate implementation
Posted by Joseph Kesselman <ke...@us.ibm.com>.
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