Lists Home |
Date Index |
- From: Paul Tchistopolskii <email@example.com>
- To: Uche Ogbuji <firstname.lastname@example.org>,Joe English <email@example.com>
- Date: Fri, 29 Dec 2000 23:14:37 -0800
----- Original Message -----
From: Uche Ogbuji <firstname.lastname@example.org>
To: Joe English <email@example.com>
Sent: Friday, December 29, 2000 9:54 PM
Subject: Re: Begging the Question
> > Most of the unfulfilling argument surrounding it springs from the
> > assumption that, since namespace names *look* like URLs, they should *act*
> > like URLs -- that is, that one should be able to to point a Web Browser
> > at them and retrieve something useful since they look like something one
> > might point a Web Browser at. This assumption, while not unreasonable,
> > is explicitly disclaimed by the namespaces spec.
> Really? Where?
Joe, this is the reason of the entire thread ;-) The spec is 'neutral' on this issue
and we've got the confirmation ( from the authors of the specification )
that this neutral wording is on purpose.
There is a timebomb in namespaces. To disable this timebomb the only
thing is needed : restrict the posibility for using URL/URIs for actual fetching
of something ( see - nobody knows *what* is that something ;-) and make it
clear in the namespace specification that namespace names are *not* for
fetching something ( that's what you are saying ;-).
Will it :
1. limit the ( extremely hypotetical ) possibilities of building some
"really bright thing" on top of those URIs ?
2. limit the possibilities of abusing it with de-facto standard ?
Look - we have I think about 5-7 candidates ( XSD, XDR, RDF e t.c. )
that could be fetched by those 'URLs-URIs' and at any point of time some
new ( yet unknown ) candidate can jump into the pool, because all of
current candidates look too weak ( sorry, I have to say this without
explaining particular weakness of each candidate. )
I think it is not sane to keep this hole open. I think it will take years
to understand what could *really* be pointed by that URL/URI and
until that - let us close the door ? Right?
Let us explicitely say that URIs should not be pointing to actual
resources, right ? What is a big deal to make such a restriction
for XML 1.0 ?
Let us look at this hole. Whatever will be attached to that URI -
it will affect almost every XML document in the world and this
could be done at any point of time. Tomorrow. Next year.
Next 2 years.
It will force people to drop all the XML schemata they'l be using
at that point of time for the sake of new, *blessed* schemata.
And this *blessed* schemata could be blessed *not* by W3C !
The wording of W3C spec allows this thing to happen and still
be 100% conformant to W3C papers!
And we have this situation on the most important part of XML,
I should say. ( Schemata is most important part of XML, I think )
I just plain don't like this situation.
If something similiar to MS XSL will happen, it will be *much* harder to
fix than "MS XSL in MS IE". Much harder.
What is a risk of closing this hole? I think nothing.
ANYWAY nobody knows what *should* get attached to those URI.
Right? It took years of arguing and still nobody can say should it
be RDF or XSD, right ?
What is a risk of *not* closing this hole?
De-facto standard on the most important part of XML.
PS. However ;-)
PPS. "Flexible" content negotiation ( the only way to protect
from de-facto abuse ) will not going work, I think.
Also if ( as it have been said many times ) this thing was
already discussed for many times, once per six months a to.co. -
and still has no resolution in some content-negotiation
proposal or something - maybe this content-negotiation
is impossible to design ?
I'm not W3C insider and I don't know the history of the
namespaces. I just learned ( from this thread ) that all the
XML books I've seen are wrong in their explanation of the
If W3C has a scenario which allows URIs be URLs and
still there is some simple way to fetch RDF | XSD | whatever
from the *same* URL ...
Well ... may I ask what will be fetched by *default* ?
... because this is how it will really work, I think.