I think it is a fallacy to embed too much meaning
into a namespace URL.
Encoding into a URL info like main, sub, and draft versions,
plus add extension names and versions, and similar will soon
end up with an ever-growing problem of trying to match
compatible namespaces in the future.
Hans
:[EMAIL PROTECTED]
Sent: Tuesday, November 07, 2006 1:07 PM
To: Recordon, David
Cc: Drummond Reed; specs@openid.net
Subject: Re: OpenID.net Service Type Namespaces
I get the hostname aspect for another namespace.
w3c[1] uses:
http://www.w3.org/ns/sss
http://www.w3.org//MM/
Recordon, David wrote:
http://specs.openid.net/authentication/2.0/signon
http://specs.openid.net/authentication/2.0/server
http://specs.openid.net/authentication/2.0/identifier_select
These seem just fine to me.
(+1, I guess!)
So very verbose and organized. There is no need for an xmlns
] On Behalf
Of Dick Hardt
Sent: Tuesday, November 07, 2006 8:09 AM
To: Recordon, David
Cc: specs@openid.net
Subject: Re: OpenID.net Service Type Namespaces
What is the concern? The argument for keeping it the current way is
for consistency. The URL resolution does not need to be trusted does
, 2006 11:56 AM
To: 'Dick Hardt'; Recordon, David
Cc: specs@openid.net
Subject: RE: OpenID.net Service Type Namespaces
My understanding is that the concern is with potential conflicts in the
actual functioning of openid.net.
Creating a clean DNS namespace for specs at specs.openid.net does seem
like
It has had some voices against it, but how about considering
this template (used in for example W3C xmldsig and
xmlenc):
http://openid.net/[year]/[month]/[project]#[type]
Time-dependent (rather than version--dependent) namespaces
can evolve freely and will not be tied down to specific
