2-stage identifier resolution

[Gretchen Greene]

Sorry but I'm a little confused where this element comes into play with
the Registry resource entity..  Does this mean each event is registered
or is there a resource with a collection of events?
I'm assuming since we've got to the detail of resolving uri's that it is
the former.  Trying to understand the scalability here with parsing,
etc. 

-Gretchen

-----Original Message-----
From: owner-registry at eso.org [mailto:owner-registry at eso.org] On Behalf
Of Norman Gray
Sent: Friday, April 21, 2006 7:09 AM
To: Ray Plante
Cc: Roy Williams; registry at ivoa.net
Subject: Re: 2-stage identifier resolution



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