OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: simple question on namespaces. Last one.

[ Lists Home | Date Index | Thread Index ]
  • From: Paul Tchistopolskii <paul@qub.com>
  • To: xml-dev@lists.xml.org
  • Date: Wed, 27 Dec 2000 21:34:30 -0800

----- Original Message ----- 
From: Paul Tchistopolskii <paul@qub.com>

> When something is *not* a URL it should *not* look like a URL. My 'invention' 
> just cleans up the mess, I think.  And I still think I'm right because I see not 
> too much rationale in your arguments.

I'm wrong.  Somehow.

After reading the letter 
From: Andrew Layman <andrewl@microsoft.com>
I'm making a bit different statement.

1. Current semantics of namespace declaration is to 
attach some hidden string to every element/attribute
in the document. The value of the string does not matter, 
the only restriction is to be unique. No hidden benefits 
for any XML processing tool.

2. Some company makes some tool ( tool X ) which 
starts abusing the namespace declaration, using URLs 
to retrieve the documents. It *is* abusing the namespace 
declaration ( because the semantics of the namespace 
declaration is (1)) , but who cares, right ?

3. I'm  XML developer. I have to design some schema 
and I also want my documents to be processed by tool X. 
Of course - I'll use URLs for my namespaces , so that tool 
X can work with my 'namespaces'. Why should I take 
something *other* than URL ? URL is fine with  
W3C paper. URL is fine with 'tool X'. - very good.

4. That's it. Now it does not matter to me  what 
is actually written in some paper on W3C website. 
Also because that paper explicitly says that 
"URLs could be used"  -  there is no contradiction. 
Just another 'de facto' standard of tool X which 

"namespaces are URLs and please : 
make this and that information accessible by URL". 

That's it. I'm doomed. See - how easy. I should now 
configure my webserver in some way that will be 
good *only* for  'tool X' .

We should just wait for first tool X to appear. I also think 
I know what will be the first company producing tool X.

I was wrong. 

Those namespaces things should be URLs, because they 
will *be*  URLs anyway. 

What is your problem with URLs PaulT ?

My problem is that the scenario  described above 
works only for *one*  company producing 'tool X'.  

If there are 2 companies, and 2 tools X and I want to 
process my documents with both of the tools, I can 
not do that. One tool may expect one thing at the 
end of URL, another tool may expect another thing at 
the end of the *same* URL , and I have URLs hardcoded 
in every document I have, because they are not my URLs!
They are my *namespaces*. Just 'tuned' a but for the sake 
of 'tool X'.

If some tool starts abusing namespaces declaration 
( using URL for retrieval ) I'm locked to that tool.

The only way to avoid this situation is to have the current 
semantics of the namespace declaration  ( see (1) - above )
and to make it hard to abuse it. 

That's why I tried to remove the http: from the URL. It makes 
a bit harder  to abuse namespaces declaration and it has all the 
current benefits of uniqueness.

Nevermind. I'm waiting for  tool X to appear. 



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS