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

Larry I think the differences between you and Jim and myself on this
topic are so fundamental that this mailing list is wrong place to hash
them out. I think the best coarse of action is for Jim and I to continue
to develop the spec in the manner in which we see fit while actively
soliciting feedback from the group. Then, at the November meeting, we
hash this issue out to the bloody end. After the conference the draft
passes from Jim and my hands to Del Jensen's. At that point Del will be
responsible for implementing whatever decisions are reached at the
November meeting.

				Yaron

>-----Original Message-----
>From:	Larry Masinter [SMTP:masinter@parc.xerox.com]
>Sent:	Friday, November 01, 1996 11:21 PM
>To:	ejw@ics.uci.edu
>Cc:	Yaron Goland; w3c-dist-auth@w3.org; ejw@ics.uci.edu
>Subject:	Re: Attribute Inclusion Criteria (was: Attributes in Prelim DAV
>Spec)
>
># 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.
>
>I think it's wrong to think that the 'source' of a resource is somehow
>'metadata'. I know it's cute when you can do that, and I've known (and
>worked on) systems that do, but it's not true that all data is
>metadata.
>
>I think really for 'obtain source' you need a link, not metadata. What
>if there's more than one source? What if one source is combined to
>create two derivatives? I think we just have to accept that the
>relationship between "retrieved resource" to "editable resource that
>generates retrieved resource" is complex, and not try to shove it into
>the metadata hole just because it sometimes fits.
>
>You might think that 'lock discovery' is also a metadata issue, but
>it's a peculiar one, because it's transient, and has less to do with
>the resource than with the manager that supports the resource. For
>example, a cached entity shouldn't become invalidated just because the
>lock state of the resource it was derived from changes. We're often
>blurring the distinction between those elements of metadata that apply
>to the resource and those that apply to the resource location.
>
>
># 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,
>
>Yes, unless your documents are songs and you want to distinguish
>between the composer and the artist. Author's common, but it's not
>universal. It will fit lots of collections, of course.
>
># "Last Modified" date is another.  Of these, some require
># standardization on the data format so their use is interoperable.
>
>Standardization of 'author' is pretty difficult. Last name first?
>First name first? Chinese given name after honorific?
>
># 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?).
>
>Well, again, HTTP defines some metadata for resource locations that
>can be thought of as distinct from metadata of the resource itself.
>(When _did_ Herman Melville write Moby Dick? Should that be the
>'creation date'?)
>
># 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.
>
>I think it will be easy to make this be the empty set.
>
># 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.
>
>I think this is also the empty set in general, although there are
>specific application profiles for which it is not.
>
>Let me try to be careful: Distributed Authoring and Versioning as a
>protocol shouldn't have any 'well known attribute sets'. However,
>there is likely a profile for 'Authoring Web Sites in 1996' which
>_does_ have a metadata profile.
>
>But don't put its specification in the DAV draft.
>
>
># 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.
>
>This isn't really metadata.
>
># 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.
>
>Date of what, though? If you just mean last modified, this is already
>part of HTTP and shouldn't be replicated somewhere else. If you mean
>something else than what's already in HTTP, I think you'll have
>difficulty finding a common requirement and use.
>
># 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?
>
>I don't see any reason for a separate DAV profile.
>
>Curmudgeonly yours,
>
>Larry
>

Received on Sunday, 3 November 1996 18:50:58 UTC