[Fwd: Re: [Handle-info] Re: HVT - A concrete example - How to implement?]

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

Hi Tony

> 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)?
>   
Yes.  HVTE can be qualified by HVTS.  This of course means that there 
will be some need for defining
some base level of bootstrapping HVTs within the type registry. This 
will get clearer as we register
and experiment with types.
> Btw, I do find the terminology a little confusing. "Encoding" is being used
> here, I guess, as a synonym for "Format". Is that right?
>   
Yes, "Encoding" is too restrictive a name and your definition of format 
is more what I had in mind.
The HVT description will include a description of the data model for 
each HVT type.

This data model can be expressed in one or more different "Formats" (The 
OpenURL triple seems
very appropriate) with Format specific character encoding.
> (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.
>
>
>
> On 13/5/08 16:40, "Christophe Blanchi" <cblanchi@cnri.reston.va.us> wrote:
>
>   
-Thanks,

Christophe




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