Hierarchical namespaces. Re: Namespace for HTML (Signup Here)

[Paul Tchistopolskii]

> Both Tim Bray and David Megginson proposed we settle on the Namespace URI
> for HTML.  I think this is a clear enough and small enough task for us
> (XML-DEV) to accomplish here and now.

I'm having impression that I'm stupid, but 
I don't think that  designing even trivial hierarchy 
is small and easy task, if  taking  into account that  
almost any hierarchy should consider future inheritance.

The URIs will appear in thousands of documents. 

I guess that folks who designed UNIX were not happy  
with  their 'creat'  syscall  ( instead of 'create' ).  

It's to illustrate my point that sometimes just one character
matters. Of course, the URIs problem it's a small problem 
if comparing it with other problems of XML. 

Anyway. The URI is very importent chunk of information 
about the namespace. Maybe it's my mistake to consider 
it to be important, but my experience shows me that 
when designing public API's spending just one day   
thinking about  good naming convention is importent.

In case that I have missed some previous attempt of 
W3C to design the structure of URI sufficient for a  long 
run, could anybody please point me the URL I can read 
on this?

> Here are some candidates:
> 
> 1) "http://www.w3.org/Markup/" - by David Megginson

The best one. I like it more than other variants. It is clear 
hierarchy :

Vendor
    Area

But it is not perfect. Were is the word HTML here?
What would be the relation with XHTML ?

I think this name could be improved to become:

http://www.w3.org/Markup/HTML

Which  would allow

http://www.w3.org/Markup/XHTML

In the future.
      
1. I don't think TR or other versioning information should 
be presented in the URI, but I'm not sure.

2. I think that because namespaces are common for all 
other standarts one should think about the flexible, 
reasonable and expandable hierarchy of namespaces.

2. I don't think  just simple prefix matching would work on 
long run. For example, I can imagine a situation when 
some new vendor comes with something 'inherited from'

http://www.w3.org/Markup/HTML/

But it would cause 

http://the.vendor.id/Markup/HTML/extension


> 2) "http://www.w3.org/HTML/1999/namespace" - by Tim Bray
> 3) "http://www.w3.org/HTML/2000/Namespace" - by Don Park (I like zeros :)

Don't think the information should be duplicated.

The URI will already appear in the 'namespace' instruction, 
so there is no need in word 'namespace'. 

I don't think information about the dates should be in 
the URI.

Vendor
    Area
        Subarea

may be enough for most cases. Unfortunately
there is no way to do some complex things with 
trivial inheritance, but I don't think it would be a 
problem. My idea is that namespaces URIs should 
not be as chaotic as they are now. 

It is public API !  Who was blaming MS ? ;-)

Again - maybe I'm missing something. 

Conclusion.

I don't think  URIs should be just some abstract and 
unpredictable strings because URIs are part of 
XML public API. Namespaces affect every part 
of XML.  'Saving' one day not designing this 
part of public API seems strange. If that 
day has been spend already - is there any way 
to check  what  was the descision ?

Rgds.Paul.

 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 paul at pault.com   www.renderx.com   www.pault.com
 XMLTube * Perl/JavaConnector * PerlApplicationServer
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)