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

Thoughts from an external observer

From: Eric van der Vlist <vdv@dyomedea.com>
Date: Sun, 21 May 2000 17:17:33 +0200
Message-ID: <3927FE0D.679E673@dyomedea.com>
To: xml-uri@w3.org
<introduction>

Covering the debate for xmlhack and xmlfr gives me -together with the
duty to read all the posts- a position of observer which I do not want
to leave to enter in the arena...

The study of these threads has left me with a couple of ideas too
personal to find their ways into articles but (maybe ?) useful for the
debate yet. 

</introduction>

<riddle>
<question>

Where can we read the following sentence "Namespaces are simply a way to
tie a specific use of a word in context to the dictionary (schema) where
the intended definition is to be found." ?

</question>
<answer>

If your answer is in the domain "microsoft.com" you're on the wrong
path.

If you've noticed the sentence from Tim Berners-Lee "if we settle for
URIs not being URIs, then RDF comes down like a house of cards", you'll
have guessed that it's from the RDF "Model and Syntax Specification",
chapter 2.2.3. "Schemas and Namespaces".

</answer>
</riddle>

<thought about="using ns URIs as pointers">

In the facts, we are already applying the point number 2 of Simon's
"status quo" : "Applications that want to go on from there could resolve
and dereference the URI on their own recognizance, retrieving a schema,
a package, a list of lightbulb jokes.".

3 examples of applications doing so have been mentioned so far :

1) RDF 

Ex: <RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
                       xmlns:DC="http://purl.org/dc/elements/1.0/">

2) Microsoft's tools

Ex: <Schema name="Schema" xmlns="urn:schemas-microsoft-com:xml-data"
xmlns:dt="urn:schemas-microsoft-com:datatypes">

3) XT (slightly different as in this case a (local) class name is
derived from the URI)

Ex: xmlns:math="http://www.jclark.com/xt/java/java.lang.Math"

I see at least 2 issues directly created by this situation :

1) These examples are all taken from open standards allowing several
namespaces to coexist in a single document and can be represented
together in a same document.

Are the applications supposed to guess if they will find a XSchema, a
RDF schema or anything else when they follow the URIs ?

2) Hot spots and network dependence.

Since xmlns:DC="http://purl.org/dc/elements/1.0/" and
xmlns:DC="http://mylocalserver.myname.com/dc/elements/1.0/" are
considered as 2 different namespaces, I won't use the second one and
applications needing to retrieve the schema will rely on the
availability of 1 single location.

This is the same problem than the XML doctype (I cannot transform a RSS
document conform to Netscape's specs on my local machine when Netscape's
site is down...).

Why couldn't we follow the suggestions to keep the namespaces as a
mechanism to disambiguate names and add a separate mechanism to link the
resources associated with the namespace ?

It would allow to define that a namespace in Dublin Core even if the
schema is on a local resource...

</thought>
<thought about="impact on XSLT">

Imagine I want to transform using XSLT doc1.xml through the identity
transformation :

doc1.xml:
<doc1 xmlns="ns1.schema"
xmlns:xinclude="http://www.w3.org/1999/XML/xinclude">
  <xinclude:include href="sub/doc2.xml"/>
</doc1>

doc2.xml:
<doc2 xmlns="ns2.schema">
  <foo/>
</doc2>

If we accept relative URIs (from my reading of the various specs) in
addition to what has been said about XPath, the xslt processors will
need to be updated to change the namespace in the output tree.

Still as a relative URI, doc2 should become :

<doc2 xmlns="sub/ns2.schema">

There are probably other cases, requiring a full impact analysis.

</thought>

Eric
-- 
------------------------------------------------------------------------
Eric van der Vlist       Dyomedea                    http://dyomedea.com
http://xmlfr.org         http://4xt.org              http://ducotede.com
------------------------------------------------------------------------
Received on Sunday, 21 May 2000 11:45:06 UTC

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