[
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.
Yes. Also, in practice most every parser is a validating parser, so
people are used to relying on this behaviour, whether they technically
should or not.
> 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.
OK. I think I'm trying to put DTDs on a par with XML Schema schemas so
that the rest of the processing isn't so XML Schema-centric. I don't
see why I shouldn't be able to assert that an attribute is of the type
declared in such-and-such a DTD when I *can* assert that an attribute
is of the type declared in such-and-such a schema.
But I agree that when it comes to parsing documents, a DTD should have
a special status.
>> 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.
I agree, especially because I imagine that DTDs for documents that
include XInclude elements are likely to default the "parse" attribute.
> 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.
My feeling is that if you need fine control over a pipeline, then you
should use a pipeline. Say that the spec said that XInclude processing
occurred prior to schema validation. That would be the default
behaviour if you specified process-xinclude="yes". But an XSLT
application could have a user option that allowed them to use a
different pipeline, thereby overriding the timing of the processing of
the XInclude. Just like an XSLT application could use a different
pipeline for dealing with the serialization process (I think Xalan,
for example, allows you to override the output method from the command
line). The XSLT 2.0 spec just needs to fix the default processing
pipeline.
I think that processing XInclude elements before validation (if at
all) is probably the right thing to do. If there wasn't a clear best
choice, the process-xinclude attribute could take values
"pre-validation", "post-validation" or "none" rather than "yes" or
"no".
> 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).
Hmm... would it actually make a difference to the processing if the
source document, containing the XInclude elements, were not a true XML
Infoset with only one document element? XInclude is still in Candidate
Recommendation -- perhaps they can be persuaded to cater for this
requirement, if it's important?
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
