W3C home > Mailing lists > Public > xml-uri@w3.org > May 2000

Re: Irony heaped on irony

From: David Megginson <david@megginson.com>
Date: Thu, 18 May 2000 16:44:04 -0400 (EDT)
Message-ID: <14628.14879.398333.651051@localhost.localdomain>
To: xml-dev@xml.org, xml-uri@w3.org
Dan Connolly writes:

 > >  The schema for schemas (and others) should reference an XML
 > > schema for the xml: Namespace using the xsi:schemaLocation
 > > attribute, as in
 > > 
 > >   xsi:schemaLocation="http://www.w3.org/XML/1998/namespace
 > >                       http://www.w3.org/XML/Schemas/xmlschema-20000518.xsd"
 > 
 > Why? Why use schemaLocation when there's no need to?

I'm too tired to rehash this whole debate for the third (or fourth?)
time -- we've fought it too many times already, for nearly two years,
and in general, the W3C WGs have done the right thing in the end (as
the Schema WG did with xsi:schemaLocation and as the XHTML WG did with
the single Namespace URI) -- so I'll summarize my position, then drop
out of the debate and let those who are less jaded continue it.

Many people (not Dan, or Tim B-L, but many of the rest of us) consider
XML namespaces to be conceptually equivalent to C++ namespaces or Java
or Perl package names -- that is, they are unique identifiers that
serve exactly two roles:

  1. group elements and attributes with different local names into a
     single collection about which general statements may usefully be
     made (i.e. "if a processor finds an unrecognized attribute in the 
     X Namespace, it should ignore it"); and

  2. disambiguate elements and attributes with the same local names.

That's it.  Period.

(Now, it happens that both of these functions provide a useful service
to schemas: (1) allows schemas to make general rules about a related
collection of element and attribute names, and (2) allows schemas to
be applied to documents with components defined by multiple
authorities.  No one, I think, disagrees with either of these
benefits.)

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.

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.

Using (or even allowing) the same mechanism for referring to both will
simply encourage confusion and the worse practice (I know that RDF
already did so, but since virtually no one is using RDF schemas in
real-world apps, that may not be much of a problem).

XML schemas should allow *only* the xsi:schemaLocation attribute and
no other mechanism, and the WG should set the example by using that
attribute itself.  If somebody insists on sticking a schema at the end
of a Namespace URI, it's hard to stop them, but at least we can point
at the practice as very sloppy engineering.

Done.


All the best,


David

-- 
David Megginson                 david@megginson.com
           http://www.megginson.com/
Received on Friday, 19 May 2000 03:32:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:42 UTC