[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Thats me with my paranoya. Really - the last one. Re: Begging theQuesti
----- Original Message ----- From: Uche Ogbuji <uche.ogbuji@f...> To: Joe English <jenglish@f...> Cc: <xml-dev@l...> 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.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|