Cart
[Home] [By Thread] [By Date] [Recent Entries]
ari@c... (K. Ari Krupnikov) wrote: | "Thomas B. Passin" <tpassin@c...> writes: |> The thought is that, if an element known to the xslt processor is |> supposed to be a literal result element, use a reserved attribute to |> say so - |> |> <template match='doc'> |> <template xslLiteral='yes'> |> ..... |> </template> |> </template> | To be safe, you'll need to put xslLiteral='yes' on *every* literal | result element because every one of them may acquire some meaning in a | future version of the spec. True. As far as this idea goes, it's probably "safer" to have the attribute assert "XSLTness" rather than "literalness". However, the notion of a reserved discriminator within XSLT doesn't quite solve the problem of a XSLT stylesheet producing another - where the discrimination semantic is needed in the output and so the attribute would have to appear in the sheet "literally". An attribute renaming facility in the control mechanism might address this (though the recursions get tricky here - how about an XSLT-sheet to produce an XSLT-sheet that will produce an XSLT-sheet?), but we could also take arms against this sea of troubles with a mechanism to *declare* the instance specific control attributes, rather than reserve their names to within the XSLT vocabulary.
|
