Subject: Attribute information

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 9 Mar 2005 10:03:51 -0500

At the meeting, I discussed the question of how to represent information 
about permissions and capabilities of LFB attributes, structure elements, etc.

Currently, we have LFB capabilities which are defined purely by the LFB 
class definition, and may tell you something about which attributes are 
supported and what permissions exist for them.  But it is not a general 
mechanism.  It does not handle arrays usefully.  It does not handle 
structure elements.

So, the suggestion I made (which is derived from discussions with model 
team members, but has not been reviewed by them) was to use the path flags 
to allow a GET or SET operation to reference information about an attribute 
or element (a path target) instead of the element itself.

The "type" of the value of such a reference would be a structure based on 
the type of the target element.  The basic structure would have a single 
element representing the permissions, with a scalar representing 
unsupported, read only, write only, and read / write.
There would be subtypes of this types for defined atomic types.
Strings would have a length element.
arrays would have information on the number of entries, first used entry, 
first unused entry, and highest used subscript.  (It is not clear to me 
whether the ability to create / delete array entries is the read-write 
property of the array, or if read-write refers to array entries and we need 
a separate create / delete.)
The information about where Aliases point would be moved here instead of a 
synthetic structure in the data, simplifying using aliases.

Does this make sense to people?
Is it a good idea?

Thank you,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 9 Mar 2005 12:26:05 -0500

Joel,

> or element (a path target) instead of the element itself.

Sounds reasonable. So the flag says "this contains metadata about the
target in this path"

> Does this make sense to people?

Clearly theres need to set things like ACL for an attribute etc.
There are some things which i think you do NOT want people to change:
like the ID - which in the latest draft is now metadata aka
xml-attribute. And i am also not sure it would make any sense for some
things to be even gettable - why would you want to get the ID of an
attribute? (I am almost having second thoughts of whether the ID should
stay as metadata - but thats a different discussion).

Also i am not sure how what you meant by strings etc being transported.

Having said that i think this is a good idea - please post some
examples.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 9 Mar 2005 21:06:44 -0500

I had originally envisioned that this would only be used with GET operations.
However, if we allow setting some fields, the ALIAS mecahnism becomes much 
simpler.

So the basic definition (not in XML, without the element identifiers) is
atomic_attribute_info: structure
     permissions; permission_scalar (not_supported, read_only, write_only, 
read_write)
   end

then we get
array_attribute_info: structure derived from atomic_attribute_info
     first_used_index: uint32
     last_used_index: uint32
     first_empty_entry: uint32
     used_entry_count: uint32
     supported_content_keys: array of uint32 (contents are key_ids)
   end
and also
string_attribute_info: structure derived from atomic_attribute_info
     actual_string_length: uint32
   end

and if we allow writing, then for alias elements we get
alias_attribute_info: structure derived from atomic_attribute_info
     target_lfb_class: uint32
     target_lfb_instance: uint32
     target_path: variable_octet_string
   end

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 10 Mar 2005 22:17:27 -0500

Joel,

Looks palatable to me. Protocol wise - a GET with that flag you
mentioned earlier to the path to, say, an alias would imply you want
to get the alias_attribute_info, correct?

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 10 Mar 2005 23:03:30 -0500

Exactly.
Thanks.  Joel