resource identifiers

[Ray Plante]

Hey Tony,

On Fri, 23 May 2003, Tony Linde wrote:
> But order need not be significant if you allow different keys:
> 
>   <ResourceID>
>     <AuthorityID>www.ncsa.uiuc.edu</AuthorityID>
>     <ResourceKey>ADIL/SIA/targeted</ResourceKey>
>     <Record>
>       <Key1>95.DR.01.01.fits</Key1>
>       <KeyX>wibble</KeyX>
>     </Record>
>   </ResourceID>
> 
> ivo://www.ncsa.uiuc.edu/ADIL/SIA/targeted?Key1=95.DR.01.01.fits&KeyX=wibble

Sorry, I wasn't making myself clear.  The most common way people compare 
URIs is by simple string comparison.  If order does not matter, this 
method will not work; instead, applications are required to parse the 
components of a URI.  This makes it harder to use Identifiers as a 
look-up key.  Obviously, this is not a problem for databases that have 
these bits all pre-parsed, but that is not the only instance such look-ups 
are done.  (In fact, record keys, since they are not persistant, are not 
likely to be used outside a formal database--e.g. a VOTable.)

As for the <Key1> etc. bit, are you suggesting that the resource that 
creates the record defines element tags that goes inside <Record>?  This 
would make things very difficult from an interoperability standpoint.  It 
would be better to say:

     <Record>
       <Key name="Key1">95.DR.01.01.fits</Key>
       <Key name="KeyX">wibble</KeyX>
     </Record>

This seems more than necessary to me as it requires that everyone use the 
key=value format for the arguments.  I think it would be better if a 
resource wants to use this format it be included in the key value 
explicitly:

     <Record>
       <Key>95.DR.01.01.fits</Key> 
       <Key>KeyX=wibble</KeyX>
     </Record>

The only one that will want to parse the second key further is the 
resource itself, because it is the only one that knows what "KeyX" means.  

cheers,
Ray