xml-dev - Thats me with my paranoya. Really - the last one. Re: Begging theQuesti

[Paul Tchistopolskii <paul@qub.com>]

----- Original Message ----- 
From: Uche Ogbuji <uche.ogbuji@fourthought.com>
To: Joe English <jenglish@flightlab.com>
Cc: <xml-dev@lists.xml.org>
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 ?

yes.

2. limit the possibilities of abusing it with de-facto standard ?

yes.

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.

Dixi.

Rgds.Paul.

PS. However ;-)

PPS. "Flexible" content negotiation ( the only way to protect 
from de-facto abuse )  will not going work, I think. 

Too complex. 

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 
namespaces.  

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.