- From: Yaron Goland <yarong@microsoft.com>
- Date: Sun, 3 Nov 1996 22:51:24 -0800
- To: "'Judith Slein'" <slein@wrc.xerox.com>
- Cc: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
> >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