RE: Attributes in Prelim DAV Spec

>
>Attributes:
>
>I find the section on attributes pretty rough going.  This is largely due to
>my own inexperience with HTTP, I'm sure.  But I also think there is a
>confusion analogous to the resource / entity confusion going on here.
>Headers are part of an HTTP message and have no persistence, but there is
>something else that is the persistent expression of an attribute.
>
>[Yaron Goland]  Headers describe the state of a resource, so long as the
>resource maintains the same state then its meta data should remain the same.
>So in a sense, meta data is persistent. Admittedly we are beating the living
>hell out of the concept, but all for a good cause. =) If attribute headers is
>too loaded a name we can just drop the header part.
>
>In section 2, you talk about using headers to communicate attributes, but in
>2.1 you say that attribute values go into the entity-body of a request.  Is
>there inconsistency here?  Or is it that when I set the value of an
>attribute, I put the value in the entity-body; but when I get the value of
>an attribute, it comes back in a header?  Does this make sense?  I'm really
>confused.
>
>[Yaron Goland]  I have added the following paragraph to section 2:
Because attribute headers may grow to very large sizes and may contain
octet data it is not feasible to include attribute headers in the header
part of a message. Rather attribute headers will be retrieved using GETs
with the value of the attribute header recorded in the entity-body. 
>
>There should be some interesting relationship between attributes and HTML
>META information.  For HTML documents, it should be possible to store
>attributes in META elements. 
>
>[Yaron Goland]  I have always been of the opinion that I should be able to
>specify a HTTP request, with headers, in HTML. A lot of the URL kludges would
>go away if we could do this.
>
>There can be attributes of attributes.  (The "abstract" attribute of a
>resource has an author and a create-date and a last-modified-date and an
>ACL.)
>
>[Yaron Goland]  Sure, that is why I defined the hierarchy concept.
>
>Attributes can be composed of other attributes.  (The "print instructions"
>attribute is composed of media type (paper or transparency), media color,
>finishing (stapled, bound, none), plex (single-sided or duplexed), etc.)
>
>[Yaron Goland]  Of course. An attribute can be a container.
>
>We need to be able to find out what attributes a resource has without
>necessarily retrieving their values.  In the context of a DMS, we may not be
>allowed to attach any arbitrary attribute to a resource -- there may be a
>fixed set that are supported, so before trying to set an attribute value, we
>
>[Yaron Goland]  That is why we have the AttributeDirectory attribute.
>
>may need to find out what attributes are allowed.
>
>[Yaron Goland]  I have added a new attribute type called AttributeSet. It
>lists what AttributeSets the resource is using. That doesn't mean all the
>attributes in a particular set are in use but rather gives a sense for what
>sorts of attributes the resource supports. That way there could be a
>"FileSystem" attribute set that defined attributes one commonly finds in file
>systems. There could be a "Z39.50" attribute set that would set attributes
>relevant to Z39.50 searches, etc.
>
>If the attribute set and / or values are very large, we might not want HEAD
>to return all of them.
>
>[Yaron Goland]  You can not retrieve the list of available attributes through
>HEAD because of the size problem. They can only be retrieved using a GET.
>Furthermore we are using SiteMaps which have the ability to point to other
>SiteMaps. So we can break up the size of the returned entity if necessary.
>Byte-Ranges are also available.
>
>When you register an attribute, you have to register with it a mime type (or
>specify an existing mime type that it uses).  The mime type would specify
>things like whether the value can be a list or must be single-valued, the
>set of valid values or range, length constraints, etc.
>
>[Yaron Goland]  That is the idea.
>
>We should encourage the use of a common set of attributes -- maybe
>referencing the work of other groups (Dublin Core, Z39.50, etc.) -- rather
>than the invention of vendor-specific attributes.  Although we have to
>support vendor-specific attributes, too.
>
>[Yaron Goland]  That is what the AttributeSet attribute is for. One can
>discover if a resource understands a particular AttributeSet.
>
>[Yaron Goland]  Great Comments!
>					Yaron
>

Received on Monday, 4 November 1996 01:51:27 UTC