"Thomas B. Passin" <tpassin@[...].net>  writes:

>  [K. Ari Krupnikov]
>  
>  So you could say that except for those
>  elements enumerated in the XSLT spec, all other ones will be treated
>  as literals. The problem /then/ is that any new version of the spec
>  that adds new elements will be backward-incompatible because it might
>  interpret literal elements as XSLT instructions.
>  
>  [Tom P]
>  
>  That is not quite the idea.  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>

This doesn't solve the problem, merely pushes it from the xmlns
attribute to xslLiteral. Your proposal lets me put literal elements
into a stylesheet that the XSLT processor might otherwise interpret as
instructions. It doesn't address the problem of elements that are not
XSLT instruction in the current version but will be in the next one.
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.

Ari.

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>