[
Lists Home |
Date Index |
Thread Index
]
ari@cogsci.ed.ac.uk (K. Ari Krupnikov) wrote:
| "Thomas B. Passin" <tpassin@comcast.net> 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.
|
