[
Lists Home |
Date Index |
Thread Index
]
> Hi Uche,
>
> > How about making an attribute on the stylesheet act as the switch?
> >
> > <xsl:transform ... xsl:version="2.0" xsl:psvi-aware="no"
> >
> > I strongly suggest the default should be no, and I think discussion
> > on this list bolsters this.
>
> The only thing that I can think of going against that is if you want
> DTDs to be treated the same way as schemas. In XSLT 1.0, source
> documents are automatically validated against DTDs, naturally, so you
> get the post-DTD-validation-infoset. You might want to maintain
> consistency with that behaviour.
I'm not sure that's right. It goes back to the whole discussion of what happens in parsing the source document. There is no reason a conforming XSLT implementation cannot use a non-validating parser which would mean it does not apply the external subset of the DTD.
I suppose your point does hold if the source doc has a significant internal subset, which must be processed in any case.
I think it would be OK in any case to consider DTDs a special case of the pipeline, which are always processed (according to XML 1.0 rules and options), and you get what you get. After all, DTDs do have special status in my view being, as they are, embedded right in XML 1.0.
> > I would also think such an attribute might put a peace to the
> > XInclude-in-source debate
> >
> > <xsl:transform ... xsl:version="2.0" xsl:psvi-aware="no"
> > xsl:xinclude-aware="yes"
> >
> > On this one, I'm neutral on the default.
> >
> > I suppose this could be done with the list-of-qnames trick:
> >
> > <xsl:transform ... xsl:version="2.0" xsl:model="psvi xinclude
> > xpipe:process-foo dsdl:process-bar"
> >
> > If you get the idea. I think I prefer the discrete attributes.
>
> That looks a lot like specifying a pipeline within a stylesheet, and I
> wonder if that gives an alternative way of looking at the issue.
>
> You could view a transformation as comprising three parts:
>
> - the parsing of the source
> - the transformation of the source
> - the serialization of the source
>
> Standalone XSLT applications carry out all three activities. XSLT
> processors, especially those invoked from code carry out only the
> second step, the actual transformation, with the parsing and the
> serialization being managed from elsewhere.
>
> There's been talk previously about whether the serialization aspect of
> the transformation process should be an optional part of XSLT, so that
> it's possible for XSLT processors to be conformant without being XSLT
> *applications*.
>
> The process of serializing to a document in XSLT is managed by an
> xsl:output element. Perhaps there should be a similar xsl:input
> element that manages the process of parsing to a PSVI, so something
> like:
>
> <xsl:input validate="strict"
> schema="myschema.xsd"
> process-xinclude="yes" />
>
> An XSLT *processor* wouldn't have to support xsl:input, but an XSLT
> *application*, that supported parsing (and most probably
> serialization) would. Note that xsl:strip-space and xsl:preserve-space
> are also really about the parsing process.
Perfectamente, Jeni. I knew it was best to wait before writing to the comments list :-)
Eric van der Vlist had reminded me of processing instructions in the stylesheet, which I would be happy to have as well, but given the politics of PIs, and the fact that your proposal parallels xsl:output, I'm in for your idea.
> Making XInclude processing standard at this level would mean
> standardising on when XInclude elements were resolved -- prior to
> validation or after validation. It doesn't address the possibility of
> resolving XInclude elements in the stylesheet (but that should
> probably be done separately) or XInclude elements in the result.
> Perhaps for the latter, xsl:output should have a process-xinclude
> attribute as well -- if anyone ever creates XInclude elements with the
> intention of them being resolved for the output, that is?!?
I think in every case it should be post DTD validation, because of the special treatment I moot for DTD. Where it stands WRT XSDL validation is certainly a question. The one thing about your xsl:input idea is that the lack of attribute order prevents it from truly allowing one to specify a pipeline.
I suppose one could use multiple xsl:input elements if order becomes significant.
A process-xinclude option for output is also a good idea. The tricky bit is that XInclude requires an infoset and XSLT can produce output without a corresponding infoset (i.e. multiple root elements).
--
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
|
