xml-dev - Re: Toward the self-describing web [was: Irony heaped on irony]

[Matt Sergeant <matt@sergeant.org>]

On Thu, 18 May 2000, Dan Connolly wrote:

> Change? From what? The best-practice for Web resource identifiers
> has always been that you can use them to access some representation of
> the
> state of the resource they identify, no? And namespaces are
> resources just like tech reports, images, and other sorts of
> documents and services and such, no?

No. Namespaces are names. Unique identifiers. Nothing more, nothing
less. They don't need to be resolved in any way shape or form. How are you
going to resolve this valid namespace uri:

	xmlns:ms="mailto:matt@sergeant.org?subject=XPathScript"

?

> Disambiguation of names is a critical feature of XML Namespaces

Right. They are disambiguous in that they are unique. That is enough to
process a document.

> but what really makes it powerful and useful is that it makes the
> web of XML documents self-describing: whenever you get a document,
> you should be able to use the namespace identifiers to figure
> out what the author of the document meant by the vocabulary
> of tags and attributes used in the document.

I completely disagree. The description or specification for the XML could
be available at the namespace, but in no way should the spec mandate that.

> We have documented this since Feb '98, when XML 1.0 became
> a recommendation despite the lack of namespace support:
> 
> 	"Therefore it is essential that when a document is written to
> 	refer to a namespace, the name space definition should be a 
> 	generic resource whose instances may include schemas in various
> 	languages at various levels of sophistication.  This is an
> 	essential growth point for the web. "
> 
> 	-- http://www.w3.org/TR/1998/NOTE-webarch-extlang-19980210#Evolving

Please also see XML Namespace Myths Exploded: Myth #1.

> 
> > We've spent over a year on XML-Dev and elsewhere explaining to the world
> > that Namespace URIs are just identifiers,
> 
> Surely the fact that Namespace URIs are identifiers is not exclusive
> with using those identifiers to access definitions of those identifiers,
> is it?

No. But requiring them to be is not backwards compatible. I also disagree
with the w3c idea that namespaces should resolve to schemas. If anything
the only thing that can truly describe what an XML format is supposed to
contain is going to be prose. If a schema validator wants a schema for an
XML file it should take one from a schema's specific attribute as
discussed already.

> I'm well aware of the bit from the namespace spec...
> 
> 	"The namespace name, to serve its intended purpose, should have
> 	the characteristics of uniqueness and persistence. It is not a
> 	goal that it be directly usable for retrieval of a schema
> 	(if any exists)."
> 
> 	-- http://www.w3.org/TR/1999/REC-xml-names-19990114/
> 
> but surely that applies just to the namespace spec, not to specs
> layered on top of the namespace spec, e.g. RDF Schemas, XML Schemas,
> my-favorite-namespace-use etc.

That's not how it's worded though, IMO. It's talking generally about
namespace expanded names.

> I think that sentence gets exploited to suggest that it's OK
> to use http://example.org/foo as a namespace name and then
> allow 404s for requests to that address, and so we should
> take it out if/when we next revise the Namespace spec.

And thus break backwards compatibility, and swamp the web with useless
requests every time an XML file gets validated. Joy.

I don't know about other people, but I'm behind a 64k link. The last thing
I need is requests coming in by XML parsers for xml lingo's I've developed
and given a namespace within sergeant.org. Don't get me wrong - I want to
use http URI's so that I _can_ put a valid description of the file. But
that should be for human eyes, IMO.

-- 
<Matt/>

Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************