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

[Christophe Blanchi <cblanchi@cnri.reston.va.us>]

Hi Tony,
> 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".
>   
This is indeed a potential use of handle value type and one that I think 
would be useful.
Service behavior, interface, for the purpose of our discussion, they 
refer to the same logical concept of a handle value pointing a specific 
service with specific set of publicly accessible operations.

> 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.
>   
I think I am missing the intent of your comment but I will take crack at it.
If a handle value is of a service reference type, it is difficult to 
know whether the content returned is dynamic or not but the application 
will know that it is talking to a service.
It is up to the application through the data returned to figure out if 
the content is dynamically generate or not.  Maybe does not matter?

From a high level of abstraction, a handle value should be typed with 
an HVT that describes how its creator intends it to be perceived (even 
if it mistaken e.g URL :) ).   The handle system will not be enforcing 
nor validating HVT to handle value relationship and it is up to the user 
to use the appropriate types or create the appropriate types.

In some case, a handle value's HVT will provide all the information/bindings/code 
needed to process its associated value, and in other cases, an external context 
from an application profile stored in the handle or an external application)
will add additional rules and operations to the HVT which will ultimately 
allow for the proper processing of the handle value. In general I think that 
the HVT typing of handle value should cover a broad range of options. 

An XML record is a good example of this late binding.  An XML record 
could be stored in a handle value and typed with an HVT (10320/XML lets say)
that only defines it as XML encoded.  The HVT only specifies encoding rules 
for it value and nothing else. Let's say that this XML contains its associated 
schema definition and  that this schema is identified using a using a handle. 
(Currently, this works using proxy handles for non compound schema reference 
and ...gulp...the URL proxy de-refencing mechanism), it is possible for an 
application to generically process that XML by determining the XML schema handle, 
resolving it and acquiring the appropiate processing rules associated
with that schema handle that will allow the application to further 
process that XML.

An HVT could also be very specifc: e.g 10320/HVT.XML.Description
In this case this HVT states that the handle value of this HVT is to 
contain and XML serialization of the HVT description according the HVT 
description schema registered under 10320/HVT.Description.Schema
(Note that the name does not/should not have to be semantically relevant)

Another example could be 10320/HVT.JSON.Description.In this case this HVT 
states that the handle value of this HVT is to contain and JSON serialization 
of the HVT description according the HVT description schema registered under 
10320/HVT.Description.Schema


The degree of completeness of description of an HVT should be flexible.  
The HVT recommendation will mostly be agnostic as far as this is concerned.

Further more, I fully expect and actual want that some HVT will describe encodings 
only, while others will describe data models only.
This is motivated by the fact that an HVT definition can extend existing 
encodings and/or data model.  As a result, I hope that a set of standard HVT 
building block types such as encoding(XML) and abstract data models (specific 
schemas, WSDL etc. ) will be created to maximize type reuse thought extension.

> 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.
>   

Actually, I think that MIME types should be registered into the handle 
value type registry.  Under what prefix and what suffix will be a contentious 
debate which I will punt on at the moment.

If you want to put a image file within a handle value, you should be able to 
specify that it is a jpg image. Clearly you could use a non handle HVT identifier 
like "MIME:image/jpg" to type your record but it would be preferable if we had 
equivalent HVT.

Note that the HVT description schema contains an Alias identification 
definition section which will enable a handle identified mime type to specify 
its MIME identifier.  This of course allows for any existing type identifier to 
be also imported into the type registry.  (UTI, and file extensions ... anyone ?)

The relationship between the HVT handle and its alias (original) identifier can 
also be described at length providing some context to the migration into the HVT 
registry.

The HVT registry will provide the ability to crosswalk from an existing 
identifier type to an HVT type and vice
versa.

Thanks,

Christophe



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