Re: [Handle-info] Re: indirect handles actually implemented?

["Hammond, Tony" <t.hammond@nature.com>]

Hi Christophe:

Thanks for the follow up and further explanation on types. So, I understand
how a type (identified by a handle) might define a service interface, e.g.

    12345/MyAPI

which would effectively class a set of service behaviours. Is that right?
Although I note you use the word "interface".

What then about specific serializations? For example, if I have an Atom
document would you treat that more or less the same but as a singleton?
There is no way to distinguish static from dynamically produced documents,
and that one may regard the serialization as a single service event.

And where, if anywhere, do mime types then fit in? For some serializations
there are valid mime types (in this case, "applicatiom/atom+xml"), whereas
for others there are none registered, or none granular enough, e.g.
"sidecar" or standalone XMP has a recommended "application/rdf+xml", but
that doesn't really say what kind of RDF/XML it is. Other serializations may
have no obvious mime types.

Cheers,

Tony




On 8/5/08 16:42, "Christophe Blanchi" <cblanchi@cnri.reston.va.us> wrote:

> Hi Tony,
>> 
>> Thanks for sharing your ideas on the type registry. Sounds like you have
>> lots of goodies planned.
>> 
>> One question must be: When? Can you give us any idea on the likely timeframe
>> when we might see some of these pieces being introduced?
>>   
> I am currently working on it.  We are planning to have it publicly
> accessible by the Brussels meeting in June.
>> For example, I note that in the 0.TYPE/URL record you have added the XML
>> description fairly recently (see below).
>> 
>> Btw, I must confess to not having understood your last comment about my
>> question on needing to qualify URL types:
>>   
> I agree with you that what URL type "means" is at best confusing at
> worst misleading.  It should
> never have been but it is a legacy type that will be grandfathered in as
> a "unwise, but useful
> and pervasive type".
> It is too late to "fix" the URL type but we can hope that future types
> will be more succinct.
> 
> The type registry, along with its various services, will make
> recommendations for creating new handle
> value types (by more or less enforcing the handle value type description
> schema) that will  encourage
> new handle value types that reference a resource to be appropriately
> specific to the type of that resource.
> 
> One can imagine a handle value type that is uniquely specific to a
> specific web service access point
> defined by nature of the reference, the transport protocol and the
> service interface.
> In that case, the handle value type can be used for all web services
> that implement a specific interface.
> e.g 10320/GoogleWebSearchAPI
> 
> Clearly, not all handle value type references will need to be so
> specific.  For example, the 10320/OpenURL
> handle value type  (defines an OpenURL handle value)  is a "smart"
> reference that intrinsically defines attributes
> of the resource/service that it references.  In this case, the handle
> value type delegates to the 10320/OpenURL
> type handler the task of figuring out what the resource points to.
> 
> 
>>> Agreed and the handle value type description, in the case of value by
>>> reference, separates the reference from the
>>> value type.
>>>     
>> 
>> As an illustration the hdl:0.TYPE/URL?index=2 value suffers exactly this
>> problem. So the value is a URL, so what? What does that "mean"? That is,
>> what's at the end of the reference?
>>   
> The 0.TYPE/URL?index=2 is there at the moment only because that is one
> of the types that the proxy knows how
> to process and we wanted a simple way to associate the URL XML type
> description with its handle while rendering it at the same time. When
> the registry is up, this record might be taken out altogether.
> 
> Thanks,
> 
> -Christophe
>>   
> 


********************************************************************************   
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
not the original intended recipient. If you have received this e-mail in error
please inform the sender and delete it from your mailbox or any other storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail or
its attachments and it is your responsibility to scan the e-mail and 
attachments (if any). No contracts may be concluded on behalf of Macmillan 
Publishers Limited or its agents by means of e-mail communication. Macmillan 
Publishers Limited Registered in England and Wales with registered number 785998 
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS   
********************************************************************************


_______________________________________________
Handle-Info mailing list
Handle-Info@cnri.reston.va.us
http://www.handle.net/mailman/listinfo/handle-info