[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Handle-info] Re: HVT - A concrete example - How to implement?
Hi Christophe:
OK, the fog is lifting. I think I'm getting it. Obviously there's many ways
to skin a cat, so I would be more than interested in seeing something
concrete which could then be comnented on. Are HVTE's primitive or can they
be qualified by HVTS's, or are both allowed (as I kind of suspect you're
suggesting)?
Btw, I do find the terminology a little confusing. "Encoding" is being used
here, I guess, as a synonym for "Format". Is that right?
(I'm not sure if we already talked about this some years back.)
What is one to make of an UTF-8 encoded bitstream, for example? Or a UTF-16
bitstream, or whatever. What does it mean?
In the OpenURL work we deliberately introduced the notion of a "Format" as a
triple:
"A Format is a method to represent information constructs as character
strings.
Each Format consists of a Serialization, a Constraint Language, and a
Constraint Definition expressed using the Constraint Language. In this
Standard, the set of three items defining a Format is called a triple
and is represented by a short-hand notation as in:
{ Serialization, Constraint Language, Constraint Definition }
"
We also had character encoding as an orthogonal construct. And both formats
and encodings were resistered items.
So, the emphasis here was very much on validation at the semantic level.
I wonder if the notion of HVTE is focussed too much on the physical
representation of an arbitrary bitstream, rather than the semantics of the
carrier serialization and of the values thqt might be carried. Encoding
seems to be the least interesting facet.
Cheers,
Tony
On 13/5/08 16:40, "Christophe Blanchi" <cblanchi@cnri.reston.va.us> wrote:
> Hi Tony,
>>
>> I'm beginning to get the fear.
>>
>> Hopefully this is nothing more than me misunderstanding the new type
>> arrangements. Otherwise I might be in trouble.
>>
> From your outlined concerns in your email, I think it is more a
> misunderstanding due to an incomplete
> description on my part.
>> If the type registry is for system defined types only, then I can follow
>> where you're going. If it's also (or an extension of it) supposed to be for
>> publicly declared user defined types, then I'm not following.
>>
>> You say
>>
>>
>>> the registration of the abstract
>>> services (as opposed to the handle value type)
>>> such as OpenHandle
>>>
>>
>> I don't know what you mean by "abstract services". OpenHandle - like many
>>
> My use of abstract service was a poor choice. What, I should have used
> was handle value type service (HVTS)
> as opposed to handle value type encoding (HVTE).
> The difference is that the HVTE specifies the encoding of the handle
> value whereas the HVTS specifies the encoding
> of a service reference (that is what is stored in the handle value),
> what the service does (its interface) and what it returns (encoding)
> The OpenHandle service you are an HVTS. You specify a service a
> reference to a service that returns a specific encoding.
>
> I just want to take this one step further and say that with the registry
> can be used to register any service. In this case
> we register the service interface and its access point. The registry
> can the be used to location a specific instance of a specific
> service interface.
>
>> other handle applications - merely gets some data from the HS (from the
>> handle values associated with the handle) and does something with that data.
>> Seems to me it's as concrete as the proxy redirect service.
>>
>> You also make a distinction between an abstract service and the "handle
>> value type" which I don't really follow. You later say this:
>>
>>
>>> Note that the abstract services will require a slightly different
>>> description schema than the one used
>>> for the handle value type.
>>>
>>
>> I had thought that the aim of "typing" was to provide a semantic classing
>> only, and to use any handle registered with that type as a convenient place
>> to locate related info such as service endpoints, apis, documentation, etc.
>>
> This is exactly the purpose that I have in mind for the registry and
> implementing at the moment.
> As far as the slight difference in description is concerned, from some
> of my experiments with
> HVT description schema and "service" description schema, it seems that
> certain fields within
> the schema might have different cardinality requirements. Again, more
> experimentation is needed.
>> If I'm following you, you seem to be suggesting that *each* instance of
>> service action (e.g. each separate format returned, or other service
>> behaviour) will require it's own type.
>>
>> You seem to be aiming for something both bigger and smaller at the same
>> time. Bigger in the sense that more would (need to) be defined:
>>
>>
>>> The registry will then provide the ability to search for services based
>>> on their interface inputs, outputs, and
>>> value added processing.
>>>
>>
>> Smaller in the sense that we are inevitably dealing with a closed set of
>> types (or one that is "open" subject to abiding by the registry
>> requirements) if registry typing is mandated/recommended.
>>
> The plan at the moment (especially since we are starting with a focus on
> HVTs ) is to provide a standardized
> description each HVT to enable the registry to enforce a minimum of
> description to allow for maximum type
> discovery and reuse. I hope you are not suggesting that we let anyone
> describe their type anyway they feel
> like using whatever scheme they want.
>
> It is anticipated that this first version of the registry will be an
> experiment that will be iterated on and refined
> for a while. We fully anticipate to have to modify any part of it,
> allow for externally defined schemata to be
> either imported into the main description schema, or simply referenced
> within the handle type and somehow
> indexed into the registry.
>> And what on earth does "value added processing" mean? Who will determine
>> that value?
>>
> Again, lack of terminology, this is only meant to talk about a service.
>> I am perplexed. It seems that the central type registry may be stifling by
>> being overly restrictive. If applications must adhere to whatever set of
>> types are provided then they will surely be limited. If, however, they can
>> choose their own types then they will have freedom to flourish, although
>> options for interop may be restricted.
>>
> I am not sure I understand your concern here. Applications will always
> be able to do whatever they want,
> there is no restrictions as to what they want to do with any handles,
> HVT or services. The registry is only there
> as a registry not as an enforcer of types.
> The only point of the registry is to provide a type sharing and
> discovery mechanism. If one wants to ignore it fine.
> I on the other handle one needs to find out about a type in order to be
> compatible with a specific application, they
> go to the registry to find out.
>> I'm wondering where that leaves me with the OpenHandle service type. Maybe
>> user applications should steer well clear of the system types?
>>
> I am not sure what trouble you here. You have built a service to
> serialize handles, you can register your service (or not)
> with the registry however you see fit. Do you want to register a HVT
> that indicates a JSON serialization of a handle value?
> Do you want to register a http based service that given a handle and
> serialization parameter expressed within a URL will
> return you that particular serialization of a handle. You can do
> whatever you see fit for the distribution of your service.
> How is that restrictive? The only restriction is that you will have to
> provide us with a description of that service that is
> compatible with what the registry expect. If that description is what
> you are concerned with, we are opened to hearing
> your suggestions.
>> I am wary also of this goal - seems a little centralized:
>>
>>
>>> value added processing. Sort of like a web yellow pages (smart web) but
>>> with typed service information which would
>>> allow you more interoperability and maybe true distributed processing.
>>>
> Again, it is only a registry not a centralized service delegation
> mechanism. I am only suggesting that a
> registry of services will enable a more interoperable distributed
> processing paradigm.
>
> Thanks,
>
> Christophe
>
>> Cheers,
>>
>> Tony
>>
>>
>> On 12/5/08 18:54, "Christophe Blanchi" <cblanchi@cnri.reston.va.us> wrote:
>>
>>
>>> 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.
>>>>>
>>>>>
>>>> So, to consider a concrete example - OpenHandle.
>>>>
>>>> This is an open source project with an API that has a clearly defined set
>>>> of
>>>> semantics. Returns one serialization (of a number of defined
>>>> serializations)
>>>> of the handle value set for a handle.
>>>>
>>>> Any ideas as to how you think this could be configured as a HVT? Under
>>>> whose
>>>> naming authority, etc.? And would it be registered in the type registry?
>>>> And
>>>> what handle values might be incorported into the HVT handle?
>>>>
>>>> There is an instance of a service running at this base URI
>>>>
>>>> http://nascent.nature.com/openhandle/handle?
>>>>
>>>> although it is not intended that this be the only service - or even the
>>>> permanent location. I did toy with the idea previously of having a
>>>> directory
>>>> of registered service endpoints, for experimental purposes registered under
>>>>
>>>> hdl:10100/openhandle
>>>>
>>>> See
>>>>
>>>> http://nascent.nature.com/openhandle/handle?format=json&id=10100/openhandle
>>>>
>>>> But that was just an early thought. Would be useful to register this
>>>> service
>>>> type with an HVT and from that to be able to locate service instances.
>>>>
>>>> Cheers,
>>>>
>>>> Tony
>>>>
>>>>
>>> As you mention, the OpenHandle could be bought into the HVT registry to
>>> dereference the location of
>>> the location of the service instance.
>>>
>>> http://nascent.nature.com/openhandle/handle?format=json&id=10100/openhandle
>>>
>>> could be expressed in a handle value as the type value combination
>>> 10320/JSON 10100/openhandle
>>>
>>> The 10100/openhandle handle will be processed according to the
>>> information (web proxy) associated
>>> with the 10320/JSON value type handle.
>>>
>>> I think that in the longer term, the registration of the abstract
>>> services (as opposed to the handle value type)
>>> such as OpenHandle into the HVT will be the logical extension of the
>>> type registry. Each service (and its interface)
>>> would have their own handles.
>>>
>>> The registry will then provide the ability to search for services based
>>> on their interface inputs, outputs, and
>>> value added processing. Sort of like a web yellow pages (smart web) but
>>> with typed service information which would
>>> allow you more interoperability and maybe true distributed processing.
>>>
>>> The type registry will have an OpenURL base service prototype to
>>> demonstrate this functionality.
>>>
>>> Note that the abstract services will require a slightly different
>>> description schema than the one used
>>> for the handle value type.
>>>
>>> -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
********************************************************************************
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