RE: Attributes in Prelim DAV Spec

I have to apologize to everyone for getting so far behind on my mail.  I
appreciate your working through my questions at this level of detail, and we
all appreciate the level of work you've been putting in on the spec.  Thanks!

More comments scattered throughout --

At 10:51 PM 11/3/96 PST, Yaron Goland wrote:
>>
>>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.

That clears up my question.  However . . .

I think the new paragraph makes it even clearer that we should be careful
about the use of the word "header".  It's definitely getting used in two
different ways here, so can we say:

"Because attribute values may grow to very large sizes and may contain octet
data, it is not feasible to include attribute values in the header part of a
message.  Rather, attribute values will be retrieved using GETs with the
attribute value 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.

Well, your example of the use of hierarchy is for a different sort of case,
more like the compound attribute case.  The <Author> attribute has a bunch
of sub-attributes <Author_FirstAuthor> <Author_SecondAuthor>, etc.
Actually, I'm a little doubtful whether this is a good mechanism for
list-valued attributes like <Author> where you can't know ahead of time how
many values there may be.  But that's another issue.

The case I'm pointing to is where one attribute itself has attributes.
Maybe the syntax here is just http://foo/bar<Abstract><Author>, where
<Author> identifies the person who wrote the <Abstract> attribute of the bar
resource.

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

OK, we need to think about the implications of this.  Now if I GET an
attribute that turns out to be composite, what I get back might be a
SiteMap.  Then I would have to follow each node in a separate GET to find
the values of all the component attributes?  We need a shortcut for this
process, to get that whole attribute value in one step.

Similarly, if I want to write the value of a composite attribute, I should
be able to do that all in one step.  Not write out the value of each
component attribute, and then write out the SiteMap.

Also, we should understand (but not specify) what it would take to process a
query against some component of a compound attribute.  (Find all the
resources with print instructions that require stapling.)

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

Thanks.

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

Thanks again.

-Judy
Name:		Judith A. Slein
E-Mail:		slein@wrc.xerox.com
Phone:  	8*222-5169
Fax:		(716) 265-7133
MailStop:	128-29E

Received on Friday, 8 November 1996 17:45:22 UTC