OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] XSLT 2.0 and XSL(-FO) 2.0

[ Lists Home | Date Index | Thread Index ]


> In the end, this is why I actually agree with what you said earlier, Ron,
> that dictating a pipeline from within XSLT is too XSLT-centric. Like
> xsl:output, it can be a good hint in restricted frameworks, but it won't
> scale (and, in fact, goes against the whole principle of pipelines to begin
> with).

I don;t think, and I expect Jeni doesn't either, that these proposals mean that the whole idea of XML processing pipelines should be subsumed to XSLT.

Of course, we need an overall pipeline spec.  And certainly I have no problem with someone being able to override hints within XSLT such as xsl:input or xsl:output with an external processing spec.

But we have a practical issue here.  There is no standard, accpted pipeline spec, and meanwhile the XSLT WG is proposing to hard-wire into the "pipeline" operations that a loud chorus here feels should be much more clearly layered.

It is in this climate that proposals such as xsl:input emerge.  It would allow us to tell an XSLT processor to knock off the PSVI nonsense.  If later on we change our minds, we can always change the stylesheet or override it externally.  Since there is no external pipeline spec, the best solution *for now* is to provide some mechanism in the XSLT transform itself to guide the building of the data model on which it will operate.  We threw in the process-xinclude example so as to illustrate how this interim mearure could address other controversies as well.  I think it's a great exaggeration to interpret this as meaning that XSLT should become *the* pipeline spec.

In fact, in one of my earlier examples, I showed how the XSLT system could refer to some externally defined pipeline.

Anyway, I'm not sure, short of the xsl:input idea, or something close to it, we can minimize the controversy of exactly how complex a data model XPath 2.0 processors should build.

Well, I do know of one way: ban PSVI from XPath 2.0 itself and move it to another spec in a separate layer.  But we've been battling over this for a good while now without any break in sight.


-- 
Uche Ogbuji                                    Fourthought, Inc.
http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
Track chair, XML/Web Services One (San Jose, Boston): http://www.xmlconference.com/
DAML Reference - http://www.xml.com/pub/a/2002/05/01/damlref.html
The Languages of the Semantic Web - http://www.newarchitectmag.com/documents/s=2453/new1020218556549/index.html
XML, The Model Driven Architecture, and RDF @ XML Europe - http://www.xmleurope.com/2002/kttrack.asp#themodel






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS