[K. Ari Krupnikov
>  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.
> 

I do not see that as a problem for __xslt__ the way things have been going -
to use version 2 you are almost certainly going to have to change your
stylesheets anyway, at least if they have any complexity about them.  So I
can't worry about your point, valid though it may be in theory.  Of course,
a similar thing in another situation might be totally backwards compatible
and yet (because of this mechanism) documents might need revisions.

For me, the real problem with control attributes is that they are not
standard but home-rolled.  Arjun seems to want us to disambiguate everything
with some combination of control attributes plus context.  We all have to
code to context, but I'll bet that just about everyone tries to minimize
context-sensitive processing whenever possible.  I'd rather not do anything
that adds to the context that needs to be handled.  Of course, namespaces
add some context too, but at least it is in a relatively standard way
instead of (again) roll-your-own.

AF may or may not be able to handle the scenarios, but few people seem to
like them.  They make it a lot harder (speaking for myself, anyway) to
understand a file by just reading it (we are in the land of human
readability here).

I hvse been involved with document designs where we had to import schemas
from multiple (4-6) other standard schemas.  I was very happy with having
each schema with its own namespace.  I thought it was a good way to for me
to make sure what was being done, and made it easy to write stylesheets to
extract data from instance documents.  It was easy for someone not
intimately familiar with the whole set of standards to know where the
various elements came from (so they could easily look up what to put in
them).

    I do not recall that we had any actual (local) name collisions, but that
could easily arise in the future since the various independent schemas are
not coordinated very much - different agencies and all that.

It is hard for me to picture another solution that would be as readable and
easy to construct.  I know that there are some hideous things you can
concoct with namespaces, and I was careful to do simple, straighforward
things to avoid them.

I was actually happy with namespaces in this project.  Maybe at some point
in the future, processing will turn out to be harder than I currently
expect, but so far so good.

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>