2-stage identifier resolution

[Norman Gray]

Ray

On 2006 Apr 20 , at 21.17, Ray Plante wrote:

> On Thu, 20 Apr 2006, Norman Gray wrote:
>> Quoth RFC3986, section 3.5:
>>
>> It's the client that dereferences the fragment: ``the fragment
>> identifier is separated from the rest of the URI prior to a
>> dereference, and thus the identifying information within the fragment
>> itself is dereferenced solely by the user agent, regardless of the
>> URI scheme.''
>
> I think this is satisfied.  The user agent strips off the fragment,  
> gives
> the IVOA ID to a registry and gets back a description containing a  
> service
> endpoint.  The agent then passes the fragment to that endpoint to  
> get the
> part of the resource--i.e., one VOEvent record.

The '#' vs. '?' could potentially support the two-step v. one-step  
alternative that you described and Roy implied.  Thus <ivo:// 
nvo.caltech/VOEventRepo#60601> is resolved in two steps, by the  
client resolving <ivo://nvo.caltech/VOEventRepo> and then querying  
for '60601' (as Roy said).  But <ivo://nvo.caltech/VOEventRepo?60601>  
is potentially resolvable on the registry, as an added-value service,  
returning a VOEvent masquerading as a VOResource.

As a side issue:

It occurs to me that there's an alternative way of handling this.  At  
the moment, IVO URIs are resolved via queries to a Registry service  
(these are still SOAP queries, aren't they?).  The alternative is to  
have an ivo-to-http mapping defined, so that this URI maps to <http:// 
ivo.example.org/nvo.caltech/VOEventRepo> or <http://ivo.example.org/ 
nvo.caltech/VOEventRepo?60601>, which can be directly dereferenced,  
or passed around in software, to read the corresponding VOResource  
directly.

This is one of the ways (indeed, it may be the most common way) that  
DOIs are resolved.  URI <doi:10.1145/945645.945664> can be resolved  
by turning it into <http://dx.doi.org/10.1145/945645.945664> and  
dereferencing it.  Easy!

The extra goodness that could come this way is that by setting the  
HTTP Accept header, you can (by design) indicate the desired format  
of the result.  Thus dereferencing <http://ivo.example.org/ 
nvo.caltech/VOEventRepo?60601> could return a VOResource _or_ a  
VOEvent depending on the Accept header.

> Which brings me to the my last point, which is most important.   
> From the
> perspective of the IVOA ID spec, there is no difference between #  
> and ?.
> So either should be fine.  On the other hand, I do not perceive any
> possible disasters either.

Indeed, and I take the point that there are two specs relevant here.

For what it's worth, I don't see any specific disasters here either.   
But the point of coding in tune with a standard's assumptions and  
design is that you don't have to be imaginative.  But if you code  
against a standard's design and assumptions, you have to think of the  
various ways things could go wrong, and the ways in which libraries,  
or proxies, or next year's clever thing will potentially mess things  
up or freeze you out. That's really all I was saying -- it wasn't  
meant to be a biggie.

All the best,

Norman


-- 
------------------------------------------------------------------------ 
----
Norman Gray  /  http://nxg.me.uk
eurovotech.org  /  University of Leicester, UK