W3C home > Mailing lists > Public > www-tag@w3.org > January 2003

Re: use of fragments as names is irresponsible

From: Joseph Reagle <reagle@w3.org>
Date: Mon, 27 Jan 2003 14:33:00 -0500
To: "Roy T. Fielding" <fielding@apache.org>
Cc: www-tag@w3.org
Message-Id: <200301271433.01258.reagle@w3.org>

>Note that all of the algorithms, methods, and other tokens are 
>named within a flat name space rooted at

Point of information on the use of '#' in the xmlsec specifications. This 
convention was borrowed from RDF at the outset of xmldsig. (I believe its 
was used in RDF because of [1] and its rules for composing identifiers). 
While I probably would not do so again, it was the best practice for 
'URI-as-identifier' known to me at the time.  This convention has been 
continued within the xmlsec related specifications (xmldsig, xenc, and now 

[1] http://www.w3.org/DesignIssues/Fragment.html
'''This means that identifiers for arbitrary RDF concepts should have 
fragment identifiers. This, in turn, means that RDF namespaces should end 
with "#".'''

It was not adopted because of any particular desire for a "flat" name space. 
(That simply wasn't our concern.) And while I don't feel strongly about:
I still do find:
convenient for namespace management. Our specifications have names/ids that 
correspond to each identifier, so describing that identifier is as simple 
as redirecting from the namespace/identifier URI to the URL of the actual 
specification. (Unfortunately, many clients forget the fragment identifier 
upon redirection...) Maintaining information in a separate structure 
corresponding to a heirchical path seemed like more bother than it merited. 
However, if one has a relatively large namespace I think it is an 
appropriate strategy and one I have asked of IANA for example.

If the TAG were to able to provide some guidance (amongst all that 
discussion <smile/>) that this practice should be discontinued I'm sure it 
would have an affect on subsequent specifications -- and perhaps even XKMS.
Received on Monday, 27 January 2003 14:33:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:36 UTC