[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[handle-dev] Re: About right this time: Handle URI parameters
Tony,
Agree, more-or-less, on URI. And we have used SWIG ourselves on the
client library to get to Python. Should work for Perl as well. We'll
send it to you (and anybody else who wants it) and I think we'll then go
ahead and include it in the distribution. So thanks for spurring that
along.
Now, as to the hard part:
We're all agreed that first category, handle parameter, independent of
syntax for the moment, e.g.,
type=URL
is a way, as you say, to refine the handle resolution, as long as we
keep in mind that 'refine' can extend to more than just indexing into
the values, e.g., requesting an authoritative answer or specifying
encoding.
And everything after that is independent of handle resolution. The
question of how many categories of parameters there are after that is
the issue.
Especially when we think about what the handle client has to know, we
come back to dividing the parameters into those that get applied to the
return value, e.g., a string for the identity of the journal article in
which the reference link appeared and which will then get tacked to the
end of the returned URL and so get sent on to the web server that the
link was pointing at, versus those that get applied to the end product
of all of this indirection, e.g., the anchor inside the article that was
being referenced in the first place and the receipt of which finally
ends this transaction.
But we've been back and forth on this and at the moment I'm not
particularly convinced one way or the other. Lets see if anyone else can
make the '3 not 2' parameter types argument better than I can.
Larry
>
> Larry:
>
> Please ignore most of the previous message - I confused handle value and
> "object" parameters - must have been thinking about the Harcourt sale :-)
> [But not all of it should be ignored - URI is right up there with IP - and
> in order to put handle "on the web" a URI encoding is a must have. Also
> support for general user agents should probably be expedited over providing
> support to browsers via plugins, Javascript, etc. (Users - who they?). Just
> need to SWIG (or XS) that C client library. If scripting languages could
> talk natively to handle and could further index into the handle...]
>
> I guess I was a little confused with some of the terms used and also with
> your original proposed syntax.
>
> > hdl!handle param?returned value param#returned object param
>
> This ordering is not conformant with RFC 2396. The string for the resource
> side to "action" follows the "?" and not the "!" character.
>
> I would say that there are only two generic syntax cases from a _client_
> perspective
>
> 1. hdl:1234/5678?
> 2. hdl:1234/5678#
>
> Case 1. is for querying into the handle and is "a string of information to
> be interpreted by the resource" (or handle server in this case). This
> refines the handle return set. This is the interesting bit.
>
> Case 2. is a string held by the client and is "additional reference
> information to be interpreted by the user agent". This corresponds to your
> "object parameter" although I don't accept this terminology. The only
> question here is not syntax but what action a client takes. Presumably the
> client would just add on this URI fragment to any URI (or URL) returned by
> the handle server.
>
> So, Case 1. deals with both handle parameters and handle value parameters.
> (Now I understand.) So handle parameters would be expressed as key/value
> pairs, eg
>
> hdl:1234/5678?index=3&type=URL&index=5
>
> would return data values for indexes 3 and 5, and all data values of type
> URL. An application would interpret these values and take appropriate
> action. I don't think one can assume any ordering as a user agent may
> simply parse the key/value pairs straight to a hash.
>
> Now for handle value parameters. These are write-through parameters. (Not
> the fragment identifiers I said they were earlier.) We only need to
> separate them from the handle parameter key/value pairs and to ensure that
> they are opaque to the URI - ie they are fully hex escaped, especially with
> regard to ampersands. Suggest that one possible separator is the bang
> character "!", as it's not reserved. One can then have something like
>
> hdl:1234/5678?index=3!%20dsy%32dasyy%26&index=4!atet
>
> Note that this does not support grouping but this may anyway be too
> complex. This would also mean that
>
> hdl:1234/5678?type=URL!tdtfi
>
> would return all handle value URLs with the querystring "?tdtfi" appended.
> (There is no way to pick out any specific URL other than by its index
> value.)
>
> An alternative solution - which could support grouping - would be to follow
> the OpenURL-type packaging (now that's why OpenURL was mentioned, doh!
> Sorry again Herbert!) and to employ a double hex encoding, where the handle
> value parameter is fully hex escaped and the [...] groups below - the "[]"
> are just for clarity - are further fully hex escaped (including the
> ampersands),
>
> hdl:1234/5678? [index=3¶m=%20dsy%32dasyy%26] &
> [index=4¶m=atet&type=URL]
>
> [...] indicates a hex escaped string.
>
> This is more general at the risk of being more complex to implement. The
> above syntax could allow for the second handle value parameter at index "4"
> to be returned if and only if it is of type URL and with the querystring
> "?atet" appended. (It is of course up to the application to do whatever
> with the actual URI returned - reolve it, display it, etc.)
>
> Think it's about right this time.
>
> Tony
>
_______________________________________________
handle-dev mailing list
handle-dev@cnri.reston.va.us
http://www.cnri.reston.va.us/mailman/listinfo/handle-dev