[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Handle-info] Re: HVT - A concrete example - How to implement?
Hi Christophe:
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.
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
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.
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.
And what on earth does "value added processing" mean? Who will determine
that value?
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'm wondering where that leaves me with the OpenHandle service type. Maybe
user applications should steer well clear of the system types?
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.
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