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.

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.

For all those attribute operations you list (discover what attributes a
resource has, set values, delete values, get values, etc.) we need to
specify what the HTTP request is like for those operations.

Some random thoughts about attributes ...

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. 

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

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

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
may need to find out what attributes are allowed.

If the attribute set and / or values are very large, we might not want HEAD
to return all of them.

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.

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.

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

Received on Thursday, 31 October 1996 19:53:29 UTC