Re: [model] section 3.2.4 Metadata

On Thu, 2006-28-12 at 14:14 -0500, Joel M. Halpern wrote:
> 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.)

This is why i avoided reading this draft for a long time so i could have
a slightly fresher perspective when looking at it. But lets keep the
discussion then we could revisit.

> 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.

Section 3.2.4.3 defines operations that can be defined on metadata.
I was using READ and WRITE as examples. 

> The idea is that relative to a given piece of metadata that an LFB 
> receives, the LFB can use it internally or not.

nod.

> 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.

nod to that too.

> (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.)
> 

My question was:
Assume two LFBs LFBa and LFBb defined by two different writers were to
operate on the same metadatum, lets say LFBa would create it (the
operation is WRITE) and that LFBb would reference it (the operation is
READ). 
Then the author of LFBa would need to formally define the metadatum s/he
creates. How is this "formally definition" achieved?
If it is in the LFB definition, then doesnt the schema need to have a
construct for it? 
I could imagine just putting a comment/documentation in the definition
which says that the LFB will create the metadata under certain
conditions. If this is the envisioned path then what is the point of
explicitly defining formal operations like WRITE or READ in? 
How does LFBb know that it can only READ but not modify the metadatum
etc? A secret handshake will do too ;->

> >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.

Does it need to be captured in the tracker?

> 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.

I think this is the crux of my earlier challenge. Where are the
semantics defined?

> 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.

Ok, is such a metadata document separate from the LFB definition then?
It may  make sense since the scope of the metadatum is global across
LFBs.

cheers,
jamal