Re: [model] section 3.2.4 Metadata

Trimmed to just the issues needing discussion.
If we can reach agreement, I would be more than happy if you took a 
crack at re-writing it.  (Part of the problem is simply that I have 
lived with the text for so long that I can't really see it straight, 
much less see it's ambiguities.)
See below.

At 11:21 AM 12/28/2006, Jamal Hadi Salim wrote:
>On Wed, 2006-27-12 at 15:33 -0500, Joel M. Halpern wrote:
> > No, the schema does not capture most of "what is meta-data".  The
> > schema does not capture all the aspects of the LFB definitions.  It
> > can't.  We did not, for example, include a programming language in
> > which to formally specify the actions of the LFB class.
>
>Looking at the metadata operations in particular: Assuming they are
>going to be used in some LFB(s), isnt it important that two different
>people defining two LFBs that may be used together within a graph
>converge on some representation of "READ" and "WRITE"
>Are you saying, perhaps, that metadata operations are local to an LFB
>and that they can define them as they see fit?

I am not sure what you mean by READ and WRITE.
The idea is that relative to a given piece of metadata that an LFB 
receives, the LFB can use it internally or not.
Also, relative to a received meta-data, the LFB can modify the value, 
discard the entire meta-data, or pass the meta-data on unmodified.
And, of course, the LFB can generate meta-data.
(The "discard" process is probably rare, but it is useful to recognize.)
The internal processing logic (both for how the LFB uses the 
meta-data value and how it creates a new value if it does) is any 
logic one can imagine.  The requirements it is to meet are given in the text.
(So, I have trouble mapping all that to read / write.)


>The other angle:
>Since we have defined metadata to comprise a 32 bit tag with a value;
>in order for those two mythical LFB writers described above to interop,
>would it not make sense to have both the tags and the values globaly
>defined and hence IANA regulated?

Meta-data tags need to be registered.  That registry is missing from 
the current draft, and unless I mess up it will be properly created 
in the next one.
The individual values do not need to be registered.
the "semantics" of the meta-data tag is basically defined by some LFB 
class that generates it.  Other LFB classes that generate it can make 
sure they have the same semantics.
So I expect to have the meta-data item name, its 32 bit tag, an 
informal description of the meaning, and references to one or more 
LFB classes in published documents that generate or use this meta-data item.
Note, this means that as far as the model document is concerned, the 
registry will be created but empty.