Re: Interpretation of XML documents with mixed namespaces [mixedNamespaceMeaning-13]

Tim Berners-Lee wrote:

> A new issue was created at the last TAG call:  what is the interpretation
> an XML document with more than one namespace.
> The document in very draft form and woefully bereft of links is
> I hope this explains the issue.  The position on solutions is all my own
> personal opinion.

In the same message, Paul opines, Top-down self-descriptiveness is one of
the major advantages of XML and I think that doing otherwise should be
deprecated. I completely agree with this conclusion. He concludes correctly
that the root namespace (the namespace of the document element) [or a
DOCTYPE, which I will not discuss further] is the only thing one must be
able to dispatch on.

Suppose for the sake of example, an RDF document, i.e. with a root element

Now various properties and elements within the document will use various

Do you mean to say that, for example a DAML application, will be required to
process the document the exact same way as an RDF application (whatever that
may be), and when OWL is specified, _the exact same way_.

Suppose, for example, the document contains a <daml:equivalentTo> element.
Are you saying that a DAML application is not allowed to make different
inferences than an RDF application given this very same document.

Indeed how do you expect a piece of software to distinguish between a plain
'ole RDF document (representing an RDF calendar entry, for example) vs. an
RDF Schema, vs a Web Ontology.

All will start with rdf:RDF.

'Dispatch', to me, means that a general application will process a document
differently depending on what it finds inside. I cannot see how one could
possibly limit oneself to the root element namespace (not that this isn't
important, and perhaps the most important single piece of information). But
to suggest: "He concludes correctly that the root namespace .. is the only
thing one must be able to dispatch on." needlessly limits what one can do
with a document. IMHO.


Received on Thursday, 28 February 2002 17:44:11 UTC