Re: Is a namespace [always] a [shared] resource?

At 08:24 AM 2000-06-09 +0100, David Carlisle wrote:
>
>
>> I think I've decided that using an offset as a name is Just Plain Dumb. The
>> question is whether it's worth doing the work to support "what the user
>> probably meant to say", or declaring that they shouldn't have said it in
>> the first place.
>
>Having thought about it further, I've decided that actually this line
>of reasoning is quite offensive (although I accept that no offence was
>intended).
>
>If I go (as I have)
>
>xmlns:x="x"
>xmlns:y="y"
>xmlns:z="z"
>
>in an XSL stylesheet to get three namespaces called x y and z for
>structuring some of the non-xsl top level elements in the stylesheet.
>Then what I "meant to say" is what I said. Since namespace names
>are not intended for dereferencing (in general and certainly not by
>a namespace parser, or xslt system) then there was no implication
>of any files called x y and z being anywhere, the namespaces are just
>called that. Namespaces can be called anything that is syntactically a
>URI reference. If I choose not to choose names that are globally
>unique, then so be it.

The URI-reference in the namespace declaration is gratuitous in this
example, too.  The prefix which serves as a local name for the namespace
suffices for all intended function. The purpose of the names in this space
is exhausted by some local communication.  There is no evidence that the
use of names in this space in this document is intended to bear any
relationship to Qnames appearing in any other document which are associated
with the same "namespace name."  The chance that the ns-attr may collide
with one used in another document is a pure downside risk.

I believe that this may be what TimBL meant by "mere programming."

There are requirements for distinguished names that are local in scope.
The idea that to introduce names one has to put them in an XML-global
space, and that anyone else creating a document which declares a name
prefix in association with the same URI-reference somehow is using "names
in the same space" is dubious of benefit and risky of outcome.  David is
not the only Unix speaker who will use /dev/null as a "random string" when
the actual fact is "It doesn't matter."  But the Namespaces Rec. doesn't
recognize the idiom or admit there is a case where it doesn't matter,
outside the current document.

This would appear to be a dysfunction:  XSL requires that one create an
extensions namespace for extensions, and Namespaces requires that all
namespaces be XML-global.  

For locally-defined XSL extensions, local names are appropriate and
XML-global names are not.  The effort to get a mid: or uuid: URL that will
keep others off your lawn is a workaround for the failure to include from
the outset a mechanism to create the local names you need.

Al


>If someone (for example me) goes to some lengths to
>write documents conforming to a W3C recommendation, then it is
>not up to the W3C to declare that I shouldn't have done that.
>
>If some overriding need arises they may have to change the spec and
>invalidate (or change the meaning of) my documents, but if so they
>should just say so and apologise, not try to make out that I was
>in anyway wrong to have followed their earlier specification.
>
>
>Actually as this example is based on xpath it is arguable that
>the absolute interpretation should have been applied anyway (although
>I'd dispute that, since xpath refers to namespace in a normative
>fashion). The stylesheet itself would of course work anyway with the
>absolute interpretation, but any stylesheet that was written to query
>into this document would break. The absolute interpretation makes
>essentially all documents that have relative namespace names become
>unusable with xpath or xslt as you never know what the namespace will
>be, and if as here the files are on the file system, the namespace
>in the file would depend on the application that reads the file.
>
>David
>

Received on Friday, 9 June 2000 07:47:58 UTC