Re: URI references and aggregation

Graham,
	Thanks for your comments; I'll give replies in-line.
					Ted
	
> It seems to me that a URL (potentially) represents such a wide range of 
> possible pointer types that calling it a "single pointer type" is kind-of 
> strange.  I find it difficult to appreciate that allowing URNs and URLs 
> really adds much in the way of complexity.  At the end of the day, they're 
> all URIs.

It's hard to argue against the point that they are all URIs at the end
of the day; they certainly are.  I also agree that the fairly regular
syntax of the URN doesn't add that much complexity.  What's driving me
in this direction, though, is that we lack a single pointer type for
referring to the feature tags.  The "unregistered" group can't be
referenced by URNs, for the reasons given below; that leaves
registering names for everything, which we've agreed isn't appropriate
for the "unregistered" group, and providing URL pointers for all of
them, which seems fairly easy to accomplish.

I actually don't object to the idea of also having URNs, but I don't
want it to be at the expense of having URL pointers to the registered
and global tags.  It may well be that the URN pointers would come into
wider or dominant use when URNs in general are more widely available.

Having selected URLs as the "uniform" pointer type for the feature
tags, there seem to be some good reasons to keep on that track for the
aggregates (which again can't be URNs).  I do think there will be a
fair amount of complexity in this system, as multiple URL schemes will
be used in the pointers.  I don't think that complexity extends into
the need to provide resolution mechanisms for all of the possible URL
schemes.  The ability to dereference these shouldn't be a
pre-requisite for this model to succeed.

> 
> > > (b) the unregistered feature tag form is defined as using URI syntax, not
> > > limited to being a URL.  So a mechanism for resolution is not necessarily
> > > always present.
> >
> >In practice, URIs are currently URLs and URNs.  My presumption is that
> >the long-term referencability requirements for URNs make them unlikely
> >choices for unregistered feature tags.
> 
> [...]
> 
> >I'm not convinced that all of the tags can be URNs (the unregistered
> >tags seem to fail the permanence test for at least some cases).  I'm
> >also not sure what the advantage is of going to a URN form; it's less
> >recognized and the resolution mechanisms are less clear.  Certainly
> >ad-hoc methods like substituion of URN:namesapce for http://host/path/
> >raise the question: why not just start with "http://host/path/" ?
> 
> OK, I've misunderstood the nature of a URN.  I was trying to capture the 
> idea of an identifier that was not bound to a specific resolution protocol, 
> like "mid:..." or "cid:..." [RFC2392].  I had not thought of these as URLs, 
> but on closer examination that's just what they are.

This is exactly the kind of identifier that I had in mind for the
hashes; it's not bound to a particular resolution protocol, but can be
used reliably as a unique key into a index of known aggregates. I
think these are likely to be used most commonly when there is a fairly
limited set of possible values.  Some of the fax folk have discussed
it as a way of short-cutting the negotiation process, and I believe it
would also be useful in some of the limited capacity wireless devices.

> 
> I agree that my proposals should not have been so URN-centric.
> 
> But I still fail to see any real advantage in excluding the use of URNs.  I 
> think they effectively
> amount to just another scheme that a limited system may or may not be able 
> to handle.
> 
> 
> 
> And other minor questions:
> 
> > > As far as I can tell, you are proposing what is, in effect, a direct
> > > mapping from feature tag to URL:
> > >
> > >     Tag --> URL
> > >
> > > and a corresponding:
> > >
> > >     Aggregate --> URL
> >
> >Yes and no.  I would retain the syntactic difference between the URL
> >pointers to Tags and those pointing to aggregates using both position
> >and markers.  I don't propose collapsing them into the same syntax.
> 
> I'm not sure what you mean here (particularly by "using both position and 
> markers").

Probably freshman linguistics haunting me (positional v.  inflected
grammars); I meant that I would not collapse the URL pointers for
aggregates into the u. faceted form for feature tags, either by
overloading that facet or by forcing them to be usable in the same
places in the grammar.  As you have noted several times, they are
different--one represents a feature and one represents a predicate.

Thanks again for your continued patience with my poor attempts at
making this clear,
			regards,
				Ted