[
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 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.
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?!?
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
