RE: Attribute Inclusion Criteria (was: Attributes in Prelim DAV Spec)

I am not going to go postal on this issue. But, we here in MS land will
define attributes which meet our needs if this group doesn't. We need
these attributes to do business. Of course Sun, Novel, Lotus, Oracle,
Netscape, and everyone else will do the same. The result will be a
billion attributes, none of which talk to each other, and the end of our
distributed authoring dream.
			Yaron

>-----Original Message-----
>From:	Jim Whitehead [SMTP:ejw@ics.uci.edu]
>Sent:	Friday, November 01, 1996 3:59 PM
>To:	w3c-dist-auth@w3.org
>Cc:	Yaron Goland; ejw@ics.uci.edu
>Subject:	Attribute Inclusion Criteria (was: Attributes in Prelim DAV Spec)
>
>>Danger! Here Be Dragons!
>
>Agreed.
>
>># This group must define a fairly robust set of attributes. Else everyone
>># will invent their own and it will take forever before things sort
>># themselves out.
>>
>>Having been at the Dublin meeting that tried to define the Dublin core
>>and watched what's happened since, I think this would be a poor
>>choice: there's no reason to believe that _this_ group could converge
>>faster on an identical problem. Why not just use the Dublin Core, for
>>that matter? Or the DMA set? Or ... well, see, part of the problem is
>>that there are so many core attribute sets around! Which to choose
>>from? Add another?
>
>First, for those who were not at the Dublin meeting (I was not, but Roy
>was, and he has described it to me), the homepage of the meeting is
>available at:
>
>http://www.oclc.org:5046/research/dublin_core/
>
>According to Roy, the meeting was held in Dublin, Ohio, where it was "damn
>cold." :-)  It was organized by Stu Weivel of OCLC, and the project has a
>definite digital library influence.
>
>An overview of the attributes recommended by this effort can be found in
>the document, "Dublin Core Metadata Element Set: Reference Description."
>
>http://purl.org/metadata/dublin_core_elements
>
>These attributes have been unified into an extensible naming scheme which
>is described in the document, "A Proposed Convention for Embedding Metadata
>in HTML," available at:
>
>http://www.oclc.org:5046/~weibel/html-meta.html
>
>Since the drafts produced at these meetings represent the result of several
>thousand person hours of effort, it seems wise to use as much of their work
>as we can in our distributed authoring and versioning effort, and we should
>certainly have a good reason for NOT using their results.
>
>>I'm guessing you won't take my advice that these things are ratholes
>>and we should desist from thinking we can solve them quickly, and
>
>I agree that this is a rathole, but one we do have to go down.  However,
>before we do, we need to set explicit bounds for how far we go into the
>hole.
>
>In order to meet the distributed authoring and versioning requirements, we
>do need to have some attributes whose name and semantics are precisely
>defined in the specificaiton.  As two examples, precisely defined
>attributes are necessary to support access to the source of a resource, and
>to support lock discovery.
>
>Beyond those attributes which are integral to our technical approach for
>meeting the requirements, there are attributes which seem to crop up in
>most "core" attribute/metadata sets.  "Author" is one, "Last Modified" date
>is another.  Of these, some require standardization on the data format so
>their use is interoperable.  For example, any date requires agreement on
>the format of the date encoded into the attribute.  Is it # of seconds
>since 1900?  Is it a string date (and which string date format?).
>
>One way of limiting the size of the attribute rathole is to have clearly
>defined criteria for the inclusion of an attribute into the DAV
>specification.  To this end, I propose the following inclusion criteria:
>
>An attribute may be included in the distributed authoring and versioning
>specification if it meets one of the following two conditions:
>1) The attribute must be integral to the technical approach described in
>the specification OR must be required to directly satisfy a distributed
>authoring and versioning requirement.
>2) The data format of the attribute must be specified to ensure
>interoperability of distributed authoring tools AND the data format for the
>attribute must not have been previously defined in an open specification
>AND the attribute must be in use in an existing Configuration Management or
>Document Management system.
>
>Examples:
>LockInformation - OK - satisfies requirement 1, since it is integral to the
>technical solution for satisfying the requirement for providing a means of
>discovering which locks are active on a resource.
>Date - OK - even though this is defined as part of the Dublin core, I could
>not find where the date format is specified.  Hence, it would be OK to
>include in the spec. a  description of how DA tools should interpret the
>data of this attribute.  Many existing systems have a Date attribute,
>Continuus/CM is one.
>Author - NO - it is allright and interoperable to interpret this attribute
>as an opaque string, so it should not be included in our spec., especially
>since it was previously defined in the Dublin core.
>
>Attributes which do not meet the criteria outlined above should be
>described in a separate document. If you are interested in taking the lead
>on the development of this document, please contact me.  I do recommend we
>include pointers to existing, openly specified attribute/metadata sets in
>the DAV specification.  I am open to suggestions from the list for
>appropriate sets to reference.
>
>I also recommend we use the hierarchical naming scheme described in "A
>Proposed Convention for Embedding Metadata in HTML," which essentially
>means we would use a "." instead of a "_" for a hierarchy separator.  We
>should also define a hierarchy name for the attributes we define in this
>specification -- "DAV" perhaps?
>
>It is my hope that by having a rigid set of criteria for inclusion of
>attributes, and by using the results of previous attribute/metadata
>efforts, we can limit the extent to which we travel down this rathole.
>
>>we'll have to have a long back and forth where I sound curmudgeonly
>>and tell you about all the problems...
>
>Of course, impudent youth is the perfect foil for the curmudgeon. :-)
>
>- Jim
>
>
>
>
>
>

Received on Friday, 1 November 1996 21:24:53 UTC