Me too!
If we can agree on a syntax, then the next step is to define
a protocol for client-server name resolution. I like SOLO's
approach, but unfortunately they don't see the need for
hierarchical name spaces, which to me and to the X.500 community
are critical to the ability to scale the service up and up and up ...
Given a simple syntax and protocol we could rapidly deploy a URN->URL
service. I have given some thought on how to manage server to server
queries to permit distributed name resolution, and think a scalable
solution could be developed in a very short space of time.
> I extended the grammar to include relative URIs, and I invented a way
> to merge URNs into the URL namespace while still begin able to tell
> them apart. A URL always looks like:
> scheme://WORD...
> or
scheme:/WORD...
> whereas a URN always looks like:
> scheme:WORD...
> (i.e. no slash)
> So we can begin to deploy things like:
> message-id:[email protected]
> isbn:IBM/832u9283
> issn:29o3u7982
Looks good to me.
> Once you've resolved a URN, you can keep that copy forever and use
> it to satisfy other queries for that URN. As to the issues of versioning,
> translation, etc., I'd say that a URNs may identify a set of documents,
> and the versions, translations, etc. are elements of the set.
Yes, but your assumption that you can keep "that copy forever" is wrong.
This depends on other factors, e.g. the expiry date of the document.
You might specify a URN for a journal and ask for the "latest" copy.
This will expire when the next edition is due.
I would like the URN syntax to support an optional set of attribute/values
as a suffix. These act to subset the set of documents identified by the
base URN. One approach for this is to use the existing "?" suffix for
URLs, another is to include the selectors in [ brackets ]. What do
you suggest for this?
> The goal is to deploy the more sophisticated "URCs" or IAFA-templates or
> whatever is a scalable, distributed fashion. In the short term, I'd like to
> be able to compose documents with references like: ...
This seems to be related to the goals behind some of the HyTime addressing
concepts. I think we need to work at this to get a deeper understanding.
Dave Raggett