Re: Minimum required of a system called "Namespaces in XML"

On Mon, Jun 05, 2000 at 06:20:27PM +0100, David Carlisle wrote:
> > yep
> (more yeps then I expected;-)

I agree with all of these. The problems I have are with using URIs
but then declaring that your not going to also use the equivalence
rules and relative addressing requirements. One of the most
basic aspects of URNs which I helped design was that they can
just name and need never be resolvable...

> > Besides, domain-names violate the persistence requirement. But yes,
> > you want decentralized assignment...
> 
> That isn't actually a requirement, just an aside pointing out good
> practice: that if you are using namespaces to get globally unique and
> persistent names, then you should use globally unique and persistent
> namespace name as a start. In fact most people seem to end up using
> http URIs as namespace names which as you say are not particularly
> persistent (cool uris don't change not withstanding). However no
> namespace processor is expected to know every uri scheme and its
> persistence properties, as it only uses the name as a string anyway
> so there is no way you can make this a requirement.
> http namespaces are clearly "persistent enough" for most purposes.

That's one of the main reasons we designed URNs. You get to assume
that any URN you see will always be bound to the thing it named.
It may not be on the network anymore but you at least know that
if I'm talking about it via its URN a thousand years from now that
I'm required to be talking about the same thing...

> > Agreed with all of this. The issue with those of us who want to 
> > build something on top of this is that the XML namespace 'name'
> > shouldn't prevent someone from attempting to resolve it. Allowing
> > a relative URI without a BASE is an error and thus makes it so that
> > the namespace 'name' prevents someone from attempting to resolve it.
> 
> It is not clear that there is anything you can not do with xmlns="foo"
> that you could do with xmlns="mailto:michaelm@netsol.com"
> you can't use either to dereference any information and while you could
> use the latter in an rdf assertion that would be an assertion about
> your mailbox, not about any namespace. If you really want to always
> have an absolute URI from every namespace name just take some fixed
> base as has been discussed before.

Sure. I'd be happy with that. Any suggestions for what that Base
should be? 

> There is absolutely no point in trying to dereference an arbitrary
> namespace name as typically you will just get a missing file error,
> so anyone specifying some system that does do this is going to have to
> say which namespace names their system works with. relative URI
> will either have to be specified to not work with the system, or the
> system will have to cope with the fact that (as is normally the case
> with relative URI) what you get if you dereference it depends on the
> current base.

Correct. An application that did attempt to resolve/retrieve something
using the namespace name it would need to say which ones had
any meaning in that regard. But what I'm trying to get at is
that the namespace name shouldn't do something that breaks the ability
of an application to do this. The lack of a Base and the non-URI
equivalence match (character-for-character) breaks my applications
ability to resolve. That doeesn't mean I want to require yours to
be retrieved or resolved. We just have to make sure we're using the
same semantics for what a URI is and what it means...

> Note that the XML 1.0 rec was carefully written _not_ to assume that
> a non validating processor had any access to any external entities.
> Of course it needs access to the document entity, if nothing else,
> about which it says

I'm in 100% agreement with this requirement....

> > This specification does not specify how the document entity is to be
> > located by an XML processor;
> > unlike other entities, the document entity has no name and might
> > well appear on a processor input stream without any identification
> > at all.
> 
> So it is explictly envisioned by the xml spec that the parser should
> not know any URI for its input, and thus would find it impossible to
> implement any newly enforced requirement to make relative URI
> absolute.
> 
> Making relative URI as namespace names allowed, except where there
> is no base URI is totally unacceptable it means that 
> cat xml-file
> (which just displays the contents on standard out) could potentially
> turn a valid document into a non conforming one.

Unless you define some universal Base (I wonder what that might look like).
"file:" is the well known base?

> Your statement would imply that the only thing discussed on this list
> is banning (or changing the meaning of) namespaces with names being a
> relative URI. That was the original topic of the list but my message
> was essentially triggered by the alarm at repeated suggestions from
> various quarters of changing the semantics of _all_ documents using
> namespaces, so that for example http://www.w3.org/1999/XSL/Transform
> and http://WWW.w3.org/1999/XSL/Transform should be "equivalent"
> namespaces or the latter should be an error, or that any URI
> at all which, when dereferenced, produced the same HTML file as the
> above should also name the "same" namespace.

Oh lordy no. If anyone is really suggesting comparing things retrieved
from tne network to in order to determine equivalence then that
is just so flat out wrong as to be silly. It completely negates things
like QOS statements, license agreements, fees, etc...

BUT, http://www.w3.org/1999/XSL/Transform and
http://WWW.w3.org/1999/XSL/Transform are equivalent URIs and IMHO, 
the namespace document should inherit that equivalence rule, not
try and come up with its own...


> Even if you ban relative URI as namespace names then you have to be
> able to answer the following question.
> 
> Take an rdf assertion about some existing resource identified by
> an absolute URI, where this resource is unconnected with namespaces.
> 
> Now consider the document
> 
> <xxx xmlns=" . . . that URI . . ." />
> 
> Questions
> 
> 1) Is this a well formed XML document conforming to the XML namespace
>    recommendation.
> 
> answer: yes

Yes....

> 2) What is the name of the namespace of the element contained in the
>    document 
> 
> answer: " . . . that URI . . ."

Yep...

> 3) Is it possible to make an rdf assertion about the namespace used in
>    this document.
> 
> answer: I don't know. But if it is it had better use a different URI
> to the rdf assertion that you started with.

Not necessarily. You could in RDF say that you are making assertions about
that URI as its treated as an XML Namespace.  For example, lets take the
case of GUIDs as defined by Microsoft. They contain a timestamp and
a MAC address. So according to your assertions they name a slice of time
on some computer with a particular NIC. Now, if I use that GUID to name
some COM object I'm not saying that the COM object represents that
slice of time, instead I'm using that unique slice of time and place
to name the COM object.

> The only really substantive objection that has been made against
> relative URI as namespace names is the fact that you can not use them
> with rdf, but until I can understand this last question (ie until
> I can understand how you can use even absolute uri for this purpose)
> I can not really get any feeling for whether or not this is a real
> problem.

Hows this:

You use RDF to say that 
URI you used      "acts as"      
 to name         ------------>   "An XML Namespace Name"
the Namespace

<rdf:RDF>
  <rdf:Description about="<your URI here>"
  <xmlnsrdf:IsA>namespace-name</xmlnsrdf:IsA>
</rdf:RDF>

(its been a while since I've read my RDF stuff so that might not
by totally accurate. This probably should be a reified statement but
you get the idea)

Once you make that statement you can make other statements about it
as a way of talking about the URI as a Namespace name regardless of
what might be at that network node if you resolve it...

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  michaelm@netsol.com

Received on Monday, 5 June 2000 14:40:19 UTC