[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Handle-info] OpenHandle: Bitmask or Boolean?
Hi Giridhar:
Many thanks for your comments. Let me reply to your two points.
1.
> (1) The Handle System specific handle types such as HS_SITE, HS_VLIST,
> HS_ADMIN (HS_NAMESPACE is missing in your list) etc are specific to
Nopes. The RDF schema is written against RFC 3651 (2003) which is the
*public specification* for the HS data model. This RFC lists seven
pre-defined data types: HS_ADMIN, HS_SITE, HS_NA_DELEGATE, HS_SERV,
HS_ALIAS, HS_PRIMARY, HS_VLIST. (And the type HS_NAMESPACE is not even
registered in the type registry - i.e. there's no 0.TYPE/HS_NAMESPACE
handle.)
See below for a commentary on the mismatch between the RFC and the current
(major) version of the HS Java release 6.2.3.
I agree that a number of aspects of the HS data model are primarily of
interest/relevance to the operation of the HS, specifically the pre-defined
HS data types and arguably five of the seven handle value fields: <index>,
<permission>, <TTL>, <timestamp>, <reference>. (The last could conceivably
be implicated as part of a user-defined data structure.) This leaves the
<type> and <data> fields of handle values of generic <type> value, which may
be the prime structures of interest for applications.
However, the following three considerations:
a) The pre-defined types have <data> structures that would normally be
exposed unless a generic/pre-defined <type> divide is being imposed.
b) The admin data fields may have some relevance to the data payload
being stored within a handle value. Especially <reference>. But then other
fields, e.g. <TTL> or <timestamp> may also have application value.
c) The primary focus is on handle value lookup, but a schema could also
serve as a basis for admin applications that would need to read/write admin
and user data.
Seems to me that it's easier to report the *complete* data structure and
leave it to applications to determine which elements they need. Also, a
future implementation of OpenHandle (or an alternate serializer using the
same schema) could choose to filter requests on <type> and/or by data field,
if transmission overhead is a consideration.
At the end of the day, I would also argue to report the *complete* data
structure as it's going to be easier to ensure consistency with the
specification rather than cherry picking those substructures and values that
are deemed to be of application read-only interest.
2.
> 10.1045/may99-payetter#index=100 is a handle. (I still need to verify
> this with other folks here at CNRI, but it looks like the syntax format
> you chose may result in a semantic collision.)
Sorry, but I may just have to usurp that query. :) The "info" record for the
"hdl" namespace is fine (as far as it goes) but neglects to mention
characters that *must* be %-encoded. That should be taken as written. (The
"info" RFC 4452 has the authority here. I know - I wrote most of it.) Any
"#" characters in the handle PREFIX or SUFFIX will need to be %-encoded.
They cannot be mistaken for the "#" in a URI.
It is thus perfectly reasonable (and unambiguous) to cite a handle - even
one containing "#" characters as e.g.
info:hdl/1234%2356.7/567%2389#index=100
For a handle value with handle "1234#56.7/567#89" and index "100". Note the
same would be true for a native "hdl:" URI scheme or a "hdl" URN namespace.
Within a URI context, URI is king, and handle must comply. Within an XML
context, XML is queen, and handle must comply. It's all about application
context.
Btw, the "hdl" registation would better have cited RFC 3651 than RFC 3650 as
there is a much fuller treatment of legal characters within a handle name.
<Handle> = <NamingAuthority> "/" <LocalName>
<NamingAuthority> = *(<NamingAuthority> ".") <NAsegment>
<NAsegment> = 1*(%x00-2D / %x30-3F / %x41-FF )
; any octets that map to UTF-8 encoded
; Unicode 2.0 characters except
; octets '0x2E' and '0x2F' (which
; correspond to the ASCII characters '.',
; and '/').
<LocalName> = *(%x00-FF)
; any octets that map to UTF-8 encoded
; Unicode 2.0 characters
3.
And now the rfc/jar handle tyoe mismatch. As mentioned aaove there are seven
handle types pre-defined: HS_ADMIN, HS_SITE, HS_NA_DELEGATE, HS_SERV,
HS_ALIAS, HS_PRIMARY, HS_VLIST. Five of these are registered in the type
registry:
0.TYPE/HS_ADMIN
0.TYPE/HS_SITE
0.TYPE/HS_SERV
0.TYPE/HS_ALIAS
0.TYPE/HS_VLIST
Two types HS_NA_DELEGATE and HS_PRIMARY are not regsitered. What gives?!
Now for the Java code. From 6.2.3, Common.java (and eliding 'public static
final byte' to avoid text wrap) we have the following:
% grep -i hs_ Common.java
... SITE_INFO_TYPE[] = Util.encodeString("HS_SITE");
... SERVICE_HANDLE_TYPE[] = Util.encodeString("HS_SERV");
... NAMESPACE_INFO_TYPE[] = Util.encodeString("HS_NAMESPACE");
... MD5_SECRET_KEY_TYPE[] = Util.encodeString("HS_SECKEY");
... PUBLIC_KEY_TYPE[] = Util.encodeString("HS_PUBKEY");
... ADMIN_TYPE[] = Util.encodeString("HS_ADMIN");
... ADMIN_GROUP_TYPE[] = Util.encodeString("HS_VLIST");
... STD_TYPE_HSALIAS[] = Util.encodeString("HS_ALIAS");
... STD_TYPE_HSSITE[] = Util.encodeString("HS_SITE");
... STD_TYPE_HSADMIN[] = Util.encodeString("HS_ADMIN");
... STD_TYPE_HSSERV[] = Util.encodeString("HS_SERV");
... STD_TYPE_HSSECKEY[] = Util.encodeString("HS_SECKEY");
... STD_TYPE_HSDSAPUBKEY[] = Util.encodeString("HS_DSAPUBKEY");
... STD_TYPE_HSPUBKEY[] = Util.encodeString("HS_PUBKEY");
... STD_TYPE_HSVALLIST[] = Util.encodeString("HS_VLIST");
...[] CREDENTIAL_TYPE_MAC = Util.encodeString("HS_MAC");
...[] CREDENTIAL_TYPE_SIGNED = Util.encodeString("HS_SIGNED");
...[] CREDENTIAL_TYPE_OLDSIGNED = Util.encodeString("HS_DSAPUBKEY");
Here, eight types are marked as standard:
HS_ALIAS
HS_SITE
HS_ADMIN
HS_SERV
HS_SECKEY
HS_DSAPUBKEY
HS_PUBKEY
HS_VLIST
Seven of which are recorded in the registry
0.TYPE/HS_ALIAS
0.TYPE/HS_SITE
0.TYPE/HS_ADMIN
0.TYPE/HS_SERV
0.TYPE/HS_SECKEY
0.TYPE/HS_PUBKEY
0.TYPE/HS_VLIST
with type HS_DSAPUBKEY being unregistered.
So, what's the story here handle people? I think the RFF schema *must*
follow the RFC as it stands, although it could be extended to also cover the
additional "standard" types. (Note we're not talking about all registered
types, such as "URL", "EMAIL", etc. but about core standard types.)
The truth must lie somewhere. For me it's the RFC, and not the Java code.
One is a public (and ratified) spec. The other is a moving target, and was
never intended to document the handle system.
Btw, I just tried to check the latest version of the distro 6.2.5_02. You
all might like to fix the permissions. It's just so super secret as
released!
% cd hdl6.2.5_02/
hdl6.2.5_02/: Permission denied.
% ls -l
total 1435744
d--------- 11 tony tony 374 18 Sep 16:34 hdl6.2.5_02/
% chmod 755 hdl6.2.5_02
% cd hdl6.2.5_02/
% ls
admintool.jar handle.jar hdlnet3sa.txt install.txt
src.zip
apidoc/ hdlnet2lic.txt history.txt
jclientlib6lic.txt
% ls -l
total 3408
---------- 1 tony tony 107192 18 Sep 16:30 admintool.jar
d--------- 18 tony tony 612 18 Sep 16:32 apidoc/
---------- 1 tony tony 885407 18 Sep 16:30 handle.jar
---------- 1 tony tony 11229 18 Sep 16:30 hdlnet2lic.txt
---------- 1 tony tony 22408 18 Sep 16:30 hdlnet3sa.txt
---------- 1 tony tony 2296 18 Sep 16:30 history.txt
---------- 1 tony tony 6920 18 Sep 16:30 install.txt
---------- 1 tony tony 2667 18 Sep 16:30 jclientlib6lic.txt
---------- 1 tony tony 691077 18 Sep 16:30 src.zip
Cheers,
Tony
On 8/2/08 21:47, "Giridhar Manepalli" <gmanepalli@cnri.reston.va.us> wrote:
> Tony,
>
> The OpenHandle serializer seems like a good gateway service to
> applications/service providers that do not understand (or trying to
> bypass) handle protocol. I have couple of questions on the serialization
> which pretty much goes back to the use case and the audience of this
> effort. It is highly likely that I mis-understood the background for
> starting this effort.
>
> (1) The Handle System specific handle types such as HS_SITE, HS_VLIST,
> HS_ADMIN (HS_NAMESPACE is missing in your list) etc are specific to
> handle protocol. These types are integral to the handle system
> functionality. There is very little value to third party applications as
> far as these types are concerned, as these types are processed during
> the resolution of the handle and retains zero-information to the
> applications. The OpenHandle serialization verbosely (for lack of
> terms) describes these types. So the question I have is: which
> applications need these protocol specific information. I understand that
> the serialization tried to define the handle record from the scratch.
> But, instead of providing RDF serialization to type/data pairs and
> leaving out the semantics of what goes into the data part to third party
> applications, the OpenHandle serializer (the draft version) seemed like
> trying to define a RDF packet for handle (transport) protocol. I would
> have understood if the expansion of data (in type/data pairs) is aimed
> for user-defined types for your specific project. But since the
> OpenHandle serializer seemed to be a generic effort, the data should be
> described to be a byte array (however encoded) with encoding type as a
> separate attribute. Also, providing a text version for this data might
> be useful. In this text, you could display a text version of HS_SITE,
> HS_VLIST etc, just so that people/applications understand what it means.
>
> (2) In the set of attributes (e.g. index, type, data, ... , reference)
> defining a handle value, the syntax you have chosen for the 'reference'
> is questionable. Quoting your comment here:
>
> "A handle reference refers to another handle value in terms
> of a UTF8-string and a 4-byte integer (where the UTF8-string is the
> handle name and the integer is the value index). For convenience a
> handle reference is implemented as a URI-ref using the "info:" URI
> scheme, where the handle value index is referenced in the fragment
> identifier. For example, a handle reference to the handle
> "10.1045/may99-payette" with index value "100" will be implemented
> as the URI "info:hdl/10.1045/may99-payette#index=100".
>
> Any series of characters following the syntax: info:hdl/<identifier> is
> a URI provided the identifier is indeed a handle identifier and complies
> with URI syntax. In your comment,
> info:hdl/10.1045/may99-payette#index=100 is pointing to index '100' of
> the handle '10.1045/may-99-payette'. But, this contradicts with the
> info:hdl syntax. Following the syntax the entire string
> 10.1045/may99-payetter#index=100 is a handle. (I still need to verify
> this with other folks here at CNRI, but it looks like the syntax format
> you chose may result in a semantic collision.)
>
> Thanks
> Giridhar
>
>
>
> Hammond, Tony wrote:
>> Hi:
>>
>> Am still plugging away at the RDF schema for our OpenHandle serializer and
>> posted a new version today at
>>
>> http://nurture.nature.com/tony/schemas/handle.rdfs
>>
>> Instances would look as the RDF/N3 copied below for <info:hdl/10101/nature>.
>> (I've posted this together with RDF/XML for the polyglot along with the
>> schema:
>>
>> http://nurture.nature.com/tony/schemas/10101_nature_new.n3
>> http://nurture.nature.com/tony/schemas/10101_nature_new.rdf [.rdf.xml]
>>
>> .)
>>
>> I've been looking at a couple principles in developing the schema:
>>
>> 0. As far as possible I've copied language directly from the RFC. In
>> some cases I've needed to patch.
>>
>> 1. Used camelcase for names (as usual practice in RDF) - properties
>> start lowercase, e.g. h:handleValues, and classes start uppercase, e.g.
>> h:HandleValue.
>>
>> (Only exceptions to class names are the pre-defined data types and acronyms,
>> e.g. h:HS_ADMIN, h:HS_SITE, ..., and h:TTL.)
>>
>> 2. As far as possible I've used names per the RFC with a couple
>> exceptions:
>>
>> a) Because the RDF data model uses a property/class breakout some new
>> terms need to be introduced (especially classes to manage constraints)
>>
>> b) To abide by #1 above I sidestepped some of the capitalizations in the
>> RFC, e.g.
>>
>> h:adminRead "true" for ADMIN_READ permission, etc.
>>
>> h:addAdmin "true" for Add_Admin permission, etc.
>>
>> (and h:listHandle "true" for the LIST_Handle permission)
>>
>> 3. Datatypes. I've tried to abide by native xsd datatypes (see schema
>> property ranges - and will add datatypes as option to RDF record). So far,
>> I've used these:
>>
>>
>> &xsd;nonNegativeInteger
>> &xsd;string
>> &xsd;boolean
>> &xsd;token
>> &xsd;anyURI
>> &xsd;unsignedByte
>> &xsd;dateTime
>>
>> Still a moving target - especially need to deal with "data" field to
>> express arbitrary data correctly in RDF/XML.
>>
>> 4. With regard to #3 I thought it would be legitimate to use
>> xsd:dataTime (ISO 8601 format) for timestamps (rather than integer number of
>> seconds, although stand to be corrected if this unwise).
>>
>> Also, for the permissions bitmasks I elected to use booleans, similar to
>> the Java code, e.g.
>>
>> boolean adminRead = true;
>>
>> <r:Property r:ID="adminRead">
>> <s:label>adminRead</s:label>
>> <s:comment>Property attributing a "ADMIN_READ" permission. This
>> permission allows the handle value to be read by any handle
>> administrator with AUTHORITIVE_READ privilege.</s:comment>
>> <s:domain r:resource="#Permission"/>
>> <s:range r:resource="&xsd;boolean"/>
>> </r:Property>
>>
>> Strictly, and following the RFC, one could define an applied bitmask xsd
>> datatype, e.g. something like
>>
>> <xsd:simpleType>
>> <xsd:restriction base="xsd:unsignedByte">
>> <xsd:enumeration value="#x01"/>
>> <xsd:enumeration value="#x02"/>
>> <xsd:enumeration value="#x04"/>
>> <xsd:enumeration value="#x08"/>
>> <xsd:enumeration value="#x10"/>
>> <xsd:enumeration value="#x20"/>
>> </xsd:restriction>
>> </xsd:simpleType>
>>
>> but I think that would add unnecessary complexity (as well as being
>> difficult to manage and reference the definitions).
>>
>> Anyway, would welcome any feedback on particulars or in general.
>>
>> Cheers,
>>
>> Tony
>>
>>
>> ####
>>
>> #Processed by Id: cwm.py,v 1.197 2007/12/13 15:38:39 syosi Exp
>> # using base file:///Users/tony/My
>> Developer/openhandle/rdfs/10101_nature_new.rdf.xml
>>
>> # Notation3 generation by
>> # notation3.py,v 1.200 2007/12/11 21:18:08 syosi Exp
>>
>> # Base was: file:///Users/tony/My
>> Developer/openhandle/rdfs/10101_nature_new.rdf.xml
>> @prefix : <http://nascent.nature.com/schemas/rdf/handle#> .
>> @prefix r: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
>>
>> <info:hdl/10101/nature> a :Handle;
>> :handleValues (
>> [
>> a :HandleValue;
>> :data [
>> a :HS_ADMIN;
>> :adminPermission [
>> a :AdminPermission;
>> :addAdmin "true";
>> :addHandle "true";
>> :addNA "true";
>> :addValue "true";
>> :authorizedRead "true";
>> :deleteHandle "true";
>> :deleteNA "true";
>> :deleteValue "true";
>> :listHandle "true";
>> :listNA "???";
>> :modifyAdmin "true";
>> :modifyValue "true";
>> :removeAdmin "true" ];
>> :adminRef <info:hdl/0.NA/10101#index=200> ];
>> :index "100";
>> :permission [
>> a :Permission;
>> :adminRead "true";
>> :adminWrite "true";
>> :publicRead "true";
>> :publicWrite "false" ];
>> :reference [
>> a :Reference;
>> :referenceCount "0";
>> r:rest () ];
>> :timestamp "2007-02-28T17:08:15Z";
>> :ttl [
>> a :TTL;
>> :ttlType "relative";
>> :ttlValue "86400" ];
>> :type "HS_ADMIN" ]
>> [
>> a :HandleValue;
>> :data <http://www.nature.com/>;
>> :index "1";
>> :permission [
>> a :Permission;
>> :adminRead "true";
>> :adminWrite "true";
>> :publicRead "true";
>> :publicWrite "false" ];
>> :reference [
>> a :Reference;
>> :referenceCount "2";
>> :referenceList (
>> <info:hdl/1234/567#index=4>
>> <info:hdl/567/1234#index=7> ) ];
>> :timestamp "2007-02-28T17:08:15Z";
>> :ttl [
>> a :TTL;
>> :ttlType "relative";
>> :ttlValue "86400" ];
>> :type "URL" ] ) .
>>
>> <info:hdl/1234/567#index=4> a :HandleValue .
>>
>> <info:hdl/567/1234#index=7> a :HandleValue .
>>
>> #ENDS
>>
>> ####
>>
>>
>>
>>
>>
>> *****************************************************************************
>> ***
>> 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
>>
>>
>
>
_______________________________________________
Handle-Info mailing list
Handle-Info@cnri.reston.va.us
http://www.handle.net/mailman/listinfo/handle-info