Re: Irony heaped on irony

Where the namespace rec defined namespace names such that "[it] is not a
goal that [a namespace URI] be directly uasble for retrieval of a
schema," but then proceeded to bind the xml prefix to a URI in the http
schema space, it was asking for trouble - a retrievable resource being a
part of the http semantic...

please, someone,
a) revise spec to bind the xml prefix a URN
a.1) specify a URN resolution mechanism to map the URN to a schema

or,
b) revise the spec to confirm, that, where an http-URL is used, the
intended use is to locate a schema.


David Megginson wrote:
> ...
> In Perl or Java, package names do not change with each new release:
> Java2 still uses the java.util package name just like Java 1.0 and
> Java 1.1 did, even though the package's contents have changed
> considerably.  Likewise, Namespace URIs should not change with each
> new revision: if or when XML 3.0 comes out, the xml: prefix should
> still be mapped to the http://www.w3.org/XML/1998/namespace URI, so
> that it's easy for software to recognize it.
> 
> While Namespace URIs should be stable, schemas obviously need to
> evolve.  It would be very dangerous silently to update the schema at
> http://www.w3.org/XML/1998/namespace if XML 2.0 adds another xml:
> attribute, since it would change the meaning of every schema that
> referenced that one; on the other hand, it would be disastrous for XML
> 2.0 processors to use a *different* Namespace URI for the xml: prefix,
> since the millions of lines of code that had a hard-coded dependency
> on the old one would break.
> 

As it is not just the namespace name, but the set of names in the
namespace which needs to be stable, use of URL's should be deprecated in
favour of persistent resource identifiers, which suggest just this behaviour.

> The solution to this problem is, or should be obvious.  We have two
> fundamentally different kinds of things -- the Namespace (or package
> name, if you prefer), which should change rarely, if at all, and the
> schema, which may change frequently, so each should be referenced with
> a different mechanism.
> 
> *

Received on Friday, 19 May 2000 06:08:04 UTC