[K. Ari Krupnikov]

Arjun Ray <aray@[...].net>  writes:

>  "Thomas B. Passin" <tpassin@[...].net> wrote:
>  | [Bill de hÓra]
> 
>  | >   - in my work with XML I've never run across a collision problem
>  | > that seemed to require namespaces. I wondering whether they're rare
>  | > or whether the markup I dela with is unusual.
>  | >
>  |
>  | The one that leaps to my mind is using an xslt stylesheet to create
another
>  | xslt stylesheet.  [...] now that I bring it up, there will probably be a
>  | lot of solutions popping up (I can see using special attributes to
indicate
>  | whether something is intended to be a literal result element or not)
> 
>  Yup.  It can be as simple as that.  The XSLT case is actually easier than
>  the general problem, because there are no overlaps.  All XSLT needs is the
>  moral equivalent of Lisp's quote/backquote operator.

That would need to be an XML mechanism, not an XSLT one. XSTL has

<template match="foo"> 
  <element name="template"> 
    <apply-templates/> 
  </element> 
</template> 

The problem is that you don't want to use it all the time; literal
result elements are very handy. 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> 

If the attribute "xsl:literal" can appear in any xsml template, we can tell
which ones are supposed to be literals.  The processor would not put the
reserved attribute into the output.  Of course, we need some escape
mechanism if we want to output a reserved literal as well, or maybe just
using the <attribute>  instruction would be enough.

Cheers,

Tom P



-----------------------------------------------------------------
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>