- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Mon, 23 Nov 1998 14:26:10 -0800
- To: "Mark D. Anderson" <mda@discerning.com>, WEBDAV WG <w3c-dist-auth@w3.org>
This is the first of a multi-part response to Mark D. Anderson's comments on
draft-ietf-webdav-protocol-09, available at:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0099.html
> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Mark D. Anderson
> Sent: Friday, October 30, 1998 7:41 PM
> To: WEBDAV WG
> Subject: a critique of webdav-protocol
>
>
> This is a long response to the draft-ietf-webdav-protocol-09.txt.
> I realize it borders on ranting; I apologize in advance for
> any toes I step on. I regret I haven't gotten to this sooner.
I too wish you had made this post sooner. To put your post in content with
the process being used to develop this protocol specification, let me note
that the WebDAV working group held two working group last call for comments
periods earlier in 1998. The first one began Monday, January 19, 1998:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JanMar/0020.html
It ended February 18, 1998:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JanMar/0206.html
Based on the extensive feedback we received during this last call period,
the draft was revised, producing draft-ietf-webdav-protocol-07. Due to the
extensive nature of the revisions, another working group last call period
was held, which began March 6, 1998:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JanMar/0252.html
This last call period ended March 29, 1998:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JanMar/0284.html
There were some changes made as a result of this last call period, which
resulted in the creation of draft-ietf-webdav-protocol-08. During my
announcement of the availability of this draft:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998AprJun/0008.html
I stated:
"It is my opinion as Chair that this draft reflects the rough consensus of
the working group. Furthermore, since there are prototype implementations
of this protocol on both client and server sides, this initial evidence
indicates the protocol is technically sound."
No one posted a message to refute this assertion.
Based on this, I sent draft-ietf-webdav-protocol-08 on to the IESG for
approval. It went through a 2 week long IETF-wide last call for comments
period in April-May, 1998, and was then forwarded to our area advisor, Keith
Moore, for his review. On October 9, 1998, Keith finished his review, and
had a list of comments on the draft. These were posted to the list:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0065.html
As a result of these comments, as well as other comments which had been
raised since the IETF Last Call, draft-ietf-webdav-protocol-09 was produced,
and a working group last call for comments period was held, beginning
Thursday, October 22, 1998:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0083.html
It ended Friday, October 30, 1998, at midnight, a few hours after you
submitted your comments. While not explicitly stated in the last call
message, the intent of this working group last call period was to review the
changes made to the draft since -08, since the working group had achieved
rough consensus on the -08 specification.
Thus you can imagine how overjoyed the editors of the protocol specification
were to receive your comments, which range over the entire specification,
and which go to the heart of core design decisions, at such a late date. :-)
> The upshot is that I think the draft is irretrievably flawed in
> conception and execution, and should not advance in the standards
> process in anything approaching the form it is in now.
However, you raise serious concerns about the specification, and hence your
comments need to be addressed.
> I realize most WG members will disagree with this conclusion;
> those who might agree probably abandoned the group long ago.
> Perhaps some of my comments will inspire minor improvements
> in the likely event that you decide to advance it.
Quoting from RFC 2026, "The Internet Standards Process -- Revision 3":
The entry-level maturity for the standards track is "Proposed
Standard". A specific action by the IESG is required to move a
specification onto the standards track at the "Proposed Standard"
level.
A Proposed Standard specification is generally stable, has resolved
known design choices, is believed to be well-understood, has received
significant community review, and appears to enjoy enough community
interest to be considered valuable. However, further experience
might result in a change or even retraction of the specification
before it advances.
Usually, neither implementation nor operational experience is
required for the designation of a specification as a Proposed
Standard. However, such experience is highly desirable, and will
usually represent a strong argument in favor of a Proposed Standard
designation.
The WebDAV specification is generally stable, has resolved known design
choices, has been understood enough to be implemented by several teams
(including teams of CS undergradutes), has received significant community
review, and does appear to have a community of interest. So, yes, I do
indend for this specification to be advanced to Proposed Standard.
> My comments are interspersed with quoted text from the draft,
> in draft order. I'm using these annotations:
> CLARITY - I don't understand it, or I think someone else won't.
> OBJECTION - An objection to what it says.
Thank you for labeling your comments -- this helped a lot.
> >Abstract
> >
> > This document specifies a set of methods, headers, and content-types
> > ancillary to HTTP/1.1 for the management of resource properties,
> > creation and management of resource collections, namespace
> > manipulation, and resource locking (collision avoidance).
>
> [OBJECTION] "collision avoidance"?
> I thought this was hashed out on the list months ago.
> Locking in an SCM system has nothing to do with lost updates.
Versioning systems like RCS do provide locking facilities which are very
similar to those provided by WebDAV. If I perform a "co -l" using RCS, this
provides me an exclusive write lock. Configuration management systems, as
opposed to versioning systems, often support locking in conjunction with
branching. So, while I am working in my own personal workspace, I will have
an exclusive write lock on my personal copy of a versioned resource.
However, in an SCM system, other people may also be working on the same
versioned resource, in their own workspaces, and each of them will also have
an exclusive write lock on the resource in their personal workspace. In an
SCm system, they they have to perform a merge of their results at some
future point.
> It isn't like locks in a programming language to protect shared
> memory.
I agree. Locks for collaborative authoring need to be long-duration, and
must be design with the knowledge that people, not programs, are driving the
taking and releasing of locks. Hence, it is acceptable for social
conventions to drive the design of collaborative locks, whereas this isn't
acceptable for programming language locks.
> Exclusive locks are for purposes of access control
In our design, we have very carefully kept locking and access control
orthogonal. While Unix-based versioning systems like RCS and SCCS use
operating system access control mechanisms as part of their enforcement of
locks, this is an implementation strategy which only makes sense for
non-networked environment.
But, for the sake of argument, let's assume that locking is performed using
access control. A lock would then translate into the operations:
restrict:
- read the current access control list (1 round trip)
- persistently store the initial access control list
- modify the access control list so that only the requestor has write
permission to the resource, but leaving all other non-write access
permissions untouched (1 round trip)
An unlock would look like:
unrestrict:
- read the initial access control list from the persistent store
- read the current access control list (1 round trip)
- modify the access control list such that the write access permissions are
the same as in the initial access control list (1 round trip)
Thus, this mechanism would result in more network round trips than the
WebDAV LOCK method (4 vs. 2). Access-control based locking would also have
the problem that if the client which took out the lock crashed, or never
re-connected to the server, the initial state of the access control list
would be lost. It might be possible to store this initial access control
list on the server, but this adds additional network round trips.
Furthermore, with access-control based locking, it is not clear how you
would implement a lock timeout feature.
As a result, an overwrite prevention scheme which uses locks, instead of
modifying access permissions, was felt to be the best design choice.
>, and
> advisory locks are for notification.
> I could do this:
> lock
> put
> unlock
> lock
> put
> unlock
> And that is no safer than:
> put
> put
In this comment, you are re-raising the thread started by Sanford Barr in:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JanMar/0176.html
After re-reading this thread, I do not believe you have raised any new
points. As a result of this thread of discussion, section 6.7 ("Usage
Considerations") was added to the specification.
Furthermore, re-stating the conclusions from this thread:
* HTTP/1.1 provides sufficient capability, with the If-[None]-Match header
to *detect* overwrite conflicts. For example, if an authoring client does
these operations:
GET resource
- save the Etag of the resource
- user edits the resource
PUT resource with If-Match of the stored Etag
If the PUT fails with a 412 (Precondition Failed), then the client knows the
resource has been modified. That is, the client can *detect* that the
resource has been overwritten. No WebDAV facilities are needed for this.
* WebDAV provides the ability to *prevent* overwrite conflicts for the
duration of an exclusive write lock. For example, if locking is added to
the previous scenario:
LOCK resource (exclusive write lock)
- save the lock token for the lock
GET resource
- save the Etag of the resource
- user edits the resource
PUT resource with If header (If is a DAV header) with stored Etag and lock
token
UNLOCK resource
If the PUT fails with a 412 (Precondition Failed), then the client knows the
resource has either been modified, or the lock has gone away (timeout or
administrative removal). In such a case, the client can retry the PUT with
just the If-Match header. If this fails with a 412 (Precondition Failed),
then the client knows the resource has been overwritten. But, importantly,
if the PUT succeeds, the client knows the resource hasn't been modified.
Furthermore, due to the lock, the likelihod of an overwrite conflict
occurring has been dramatically reduced. That is, the lock serves to
prevent overwrite conflicts.
> In both cases, the server should ensure that a PUT is atomic
> and independent (in case simultaneous PUT operations hit the
> server). The server can certainly not rely on client-side
> locking for that; it requires its own.
Agreed. Since PUT is defined in HTTP/1.1 (RFC 2068), it is not clear to me
that the WebDAV specification is the best place to put an implementation
note such as this. The other reason why a PUT needs to be independent is to
account for the fact that a PUT operation could have its network connection
dropped mid-way through the operation.
But, this comment doesn't really raise any new information. These
implementation points are well-known within the HTTP server implementor
community, and there are several existing implementations of HTTP 1.1 PUT
which get it right.
> In both cases, the server may simply overwrite the previous
> value of the resource, or may automatically increase a version.
> In both cases, the server may support a protocol extension whereby
> a PUT is sent with a header specifying a particular version, and
> the server may reject the PUT if that version isn't still the most
> recent (or the "default"). But that server extension might be
> supported in either case, and has nothing to do with (client-side)
> locking.
The Versioning and Variant Authoring Design Team is considering issues of
how to perform "automatic" versioning, which encompasses features similar to
what you describe here. You may wish to join the discussion of this
capability on the versioning discussion list by sending a message with
"Subject: subscribe" to ietf-dav-versioning-request@w3.org. The current
versioning protocol document is draft-ietf-webdav-versioning-00.
> > Properties: The ability to create, remove, and query information
> > about Web pages, such as their authors, creation dates, etc. Also,
> > the ability to link pages of any media type to related pages.
>
> [CLARITY] What is the import of the phrase "of any media type"?
Media type is used here with the same meaning as in the HTTP/1.1
specification, RFC 2068, and the MIME document series (RFC 2045-2049).
Specifically, media type, content type, and MIME type are all synonyms. So,
what we are saying is that properties can be stored on any resource, no
matter its content type.
But, if you were confused by this term, others might be too, so we added a
brief note of clarification to section 4.6 ("Media Independent Links").
> Also, must we use the term "page"? It shows the document-centric
> bias of the authors.
I think that once you realize that media-type independent means "any content
type" this doesn't display as much of a document-centric bias. Furthermore,
this paragraph is in the introduction, and is intended to ease readers into
the draft. We felt it would be less complex initially to not list all the
possible ramifications of media-type independence.
> Does the last sentence of the paragraph
> above really just mean "the ability declare a relation between
> any two resources"?
Yes.
> > Collections: The ability to create sets of related documents and to
> > retrieve a hierarchical membership listing (like a directory listing
> > in a file system).
>
> [CLARITY] I would suggest removing the word "related", as that suggests
> more than what is supported (for example, maintenance of consistency).
> And in the case of a DMS which has a single top-level collection
> (http://dmsgateway.mycompany.com/dms/$docid), the resources are not
> necessarily related in any meaningful way.
Point taken.
> Also, if the draft specifies how to retrieve a hierarchical membership
> listing, I missed it (see my suggestion for OPTIONS below).
The PROPFIND method can be used to retrieve a listing of the members of a
collection. This was discussed on the list:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1997OctDec/0160.html
http://lists.w3.org/Archives/Public/w3c-dist-auth/1997OctDec/0172.html
> > Locking: The ability to keep more than one person from working on a
> > document at the same time. This prevents the "lost update problem,"
> > in which modifications are lost as first one author then another
> > writes changes without merging the other author's changes.
>
> [OBJECTION] See above regarding "collision avoidance".
See my comments above concerning your comments.
>
> > Requirements and rationale for these operations are described in a
> > companion document, "Requirements for a Distributed Authoring and
> > Versioning Protocol for the World Wide Web" [RFC2291].
>
> [CLARITY] It would be helpful to indicate that this document does
> not discuss versioning.
Point taken.
> > In HTTP/1.1, method parameter information was exclusively encoded in
> > HTTP headers. Unlike HTTP/1.1, WebDAV encodes method parameter
> > information either in an Extensible Markup Language (XML) [REC-XML]
> > request entity body, or in an HTTP header. The use of XML to encode
> > method parameters was motivated by the ability to add extra XML
> > elements to existing structures, providing extensibility; and by
> > XML's ability to encode information in ISO 10646 character sets,
> > providing internationalization support. As a rule of thumb,
> > parameters are encoded in XML entity bodies when they have unbounded
> > length, or when they may be shown to a human user and hence require
> > encoding in an ISO 10646 character set. Otherwise, parameters are
> > encoded within HTTP headers. Section 9 describes the new HTTP
> > headers used with WebDAV methods.
>
> [CLARITY] There should be some minimal discussion as to why
> webdav should be an HTTP extension at all, rather than its own
> protocol. I don't think this is a difficult case to make, but
> it should be made (the key issue being whether this is a true
> extension, or mere protocol tunneling).
I disagree. When writing a protocol specification, there is a tradeoff to be
made on how much design rationale (or non-normative text in general) should
be included in the specification. On the one hand, it is helpful to have
the design rationale so that future readers will understand some of the
choices made in creating the specification. This argues for adding as much
design rationale as possible. On the flip side, there are protocol critics
who will simply look at the length of a specification, and criticize it
based exclusively on its length in pages, without looking at the content of
these pages to see whether they are full of normative requirements, or
instead have helpful design rationale or protocol examples. Furthermore,
the longer the document, the longer it takes to review, and the harder it is
to find reviewers. It takes longer to make a new revision of a long draft.
These points all argue against adding a lot of non-normative text to a
specification.
In my view, the WebDAV protocol specification needs a companion design
document, or an annotated specification, similar to what has been done with
the XML specification (see http://www.xml.com/axml/testaxml.com). But I
think adding a lot of this text to the WebDAV specification itself is a
mistake.
> There should be more precise guidelines for whether a parameter
> is placed in a http header or body. The considerations given in
> the draft are character set, and size. It is perfectly possible to
> encode richer character sets in http headers (see rfc2047); that is
> irrelevant.
The problem with RFC 2047 is you sacrifice easy human readability -- XML
doesn't have this problem.
> Size is a valid consideration. Another vital
> consideration is who is expected to look at it: if proxies need
> to look at it, or if a web server needs to look at it in early
> stages of request processing (for access control!), and if CGI
> programs will not be interested, then a http header is a good
> place for it. Sometimes a strict subset of those criteria
> obtains, and then it is a hard decision. There should be some
> indication as to whether the preferred location is the header or
> the body. Some consideration should be given to a server being
> flexible about a parameter appearing in either location (or both).
As you might imagine, we spent considerable time in our design on the issue
of how best to encode parameters into an HTTP message. Certainly some
discussion of this issue should go into the future WebDAV design document.
But I fail to see how discussing this rationale in the protocol
specification itself would aid interoperability of clients and servers
written to this specification. This information could be of use to future
protocol designers who wish to emulate WebDAV's style of embedding
parameters in the message body, but then that's why they would read the
design documentation.
> [OBJECTION] There should be guidelines for the syntax of webdav parameters
> placed in http headers. The protocol as stated violates the guidelines in
>
> http://www.ics.uci.edu/pub/ietf/http/draft-frystyk-http-extensions-00.txt
> and in
> http://www.w3.org/TR/WD-http-pep
>
> The interrelationship between the IETF and W3C standards processes
> constantly bewilders me -- particularly in cases such as this where
> the same author is involved -- but it does seem like acknowledgment
> of at least one of them is merited. Both site webdav after all.
> The two differ; the ietf draft is simpler (and so more attractive)
> while the w3 draft seems to have thought through better how
> convergence into later http base versions will work. How to do
> extensions is a particularly important issue for webdav, what with
> its scattering of related efforts (dasl, versioning, acl, etc.) --
> it needs an explicit strategy for how protocol extension and
> interop will occur. The proposal should also explicitly state a
> connection (if not identity) between a versioned URI appearing
> as part of an XML xmlns declaration, and a URI that might occur
> as part of a PEP-related HTTP header.
First, draft-frystyk-http-extensions-00 is by no means guaranteed to ever
become a Proposed Standard, and hence (as WebDAV has demonstrated with
UUIDS, and XML Namespaces), it is dangerous to base your work on drafts
which have not yet been approved. Beyond that, this draft appears to
address extensions to HTTP which have not gone through a formal
standardization process, as WebDAV has. Thus, I think it is in WebDAV's
best interests to work cooperatively on the development of this draft, but
certainly not to follow it.
As for PEP, http://www.w3.org/TR/WD-http-pep, it is currently a dead
proposal. It does not have sufficient support to ever be approved, and as
far as I know, the W3C is not working on it any further. I also have
numerous technical complaints about this draft, which I will not go into
here.
> [OBJECTION] The document should state up front what general guidelines
> should be used in the structuring of the XML request bodies, that
> hold for all protocol requests in webdav. It should state whether
> the body is to be interpreted as a single parameter value, a subset of
> the parameter values (the rest being in the header), or the entire
> parameter set.
>
> It should not be the case that request and response formats are
> restricted only by what is expressible by a DTD; there should be
> some articulation of the underlying thought behind their structure
> to guide further extension and implementation. The abstract model
> behind what is specified in Appendix 1 escapes me. At a glance,
> it looks ad hoc, and so would have to be special-cased and
> hard-wired by a server implementation, probably per method.
This is another case where the tradeoff between adding more design
information and keeping the draft concise collide. I agree that information
like this should certainly appear as part of the design document.
There are logical groupings of the elements in the DTD in Appendix 1 -- the
line spacing is used to try to indicate some of the logical groupings. I
agree that these don't have as much cohesion as the elements in a typical
document might have -- on the other hand, these aren't being used to create
documents, but rather to marshall parameters.
> At a glance,
> it looks ad hoc, and so would have to be special-cased and
> hard-wired by a server implementation, probably per method.
I think we would have created far more problems for ourselves if we had
tried to bite off the problem of creating a general-purpose remote
proceedure call marshalling syntax. Since there are currently several
competing proposals in this space, and given their dependency on XML efforts
to add data typing to XML, I think it was a wise decision to not base our
efforts on these other efforts, since it allows us to finish before, say,
the year 2002.
> >3 Terminology
> >
> > URI/URL - As defined in [RFC2396].
> >
> > Collection - A resource that contains member resources and meets the
> > requirements in section 5 of this specification.
> >
> > Member Resource - A resource contained by a collection.
> >
> > Internal Member Resource - A member resource of a collection whose
> > URI is immediately relative to the URI of the collection.
>
> [CLARITY] You should also define "Resource" (perhaps also with reference
> to that rfc).
Sure, and we could also redefine every element in the terminology section of
RFC 2068. I wasn't that keen on adding the definition of URI and URL
either -- it seems to me that if you're writing an extension to HTTP, it is
reasonable to expect your readers will have read the HTTP spec., and will
know what a resource is.
> [OBJECTION] The document is consistently muddled throughout about
> resources (the semantic entities) versus their various identifiers (URI).
> Take even the phrase "whose URI" above -- implying that there always is
> such a unique mapping (this is usually taken to be the case only
> for URNs).
> More on this later, concerning section 5.
This problem was previously noted by Larry Masinter:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0227.html
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0021.html
See also:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0152.html
There were many modifications to the WebDAV protocol specification from -08
to -10 which substantively addressed this problem. For details, see:
http://www.ics.uci.edu/pub/ietf/webdav/protocol/dav-09-to-10.html
http://www.ics.uci.edu/pub/ietf/webdav/protocol/dav-08-to-09.html
> > Property - A name/value pair that contains descriptive information
> > about a resource.
>
> [CLARITY] A "pair"? So is this some novel entity, which is not itself a
> resource? Is it URI-addressable?
People often call what we term properties "attribute-value pairs", and the
term "pairs" was meant to evoke this.
> > Live Property - A property whose semantics and syntax are enforced
> > by the server. For example, the live "getcontentlength" property
> > has its value, the length of the entity returned by a GET request,
> > automatically calculated by the server.
> >
> > Dead Property - A property whose semantics and syntax are not
> > enforced by the server. The server only records the value of a dead
> > property; the client is responsible for maintaining the consistency
> > of the syntax and semantics of a dead property.
>
> [CLARITY] "Dead" has connotations of a need for garbage collection.
> How about "automatic" or "dynamic" as compared to "passive" or "static"?
Once you have an entire community which has built up a shared meaning around
a set of terms, it usually doesn't make sense to change those terms, even if
they are not the best possible terms. My favorite example is the
Association for Computing Machinery, a US-based professional society for
computer scientists. Obviously their activities range far beyond
discussions of "machinery", but they have decided that the value of the
"ACM" brand outweight the cost of changing, and the benefits to be had from
the change.
Similarly, while we could spend a lot of time figuring out the best possible
terms for "live" and "dead", the DAV community knows what I mean when I say
these terms, and they communicate well to people outside the community too.
Thus I see little value in changing them at this point.
> [OBJECTION] This is just a halfway stab at addressing the more
> fundamental issue of how to represent metadata about properties:
> what are their accepted values, and so on. Do you expect every
> server implementation to just keep a compiled-in table
> of which properties are live or dead?
Yes, I do expect servers to have a persistent, static representation of
which properties are live or dead.
> There needs to be
> a representation of "properties of properties" that is web-addressable
> and automatically parseable. This is one reason why properties
> in RDF (what they used to call "PropertyTypes") are resources.
This issue has surfaced in the past as the "schema discovery" issue.
Because RDF is working on this issue, and because the complexity of this
issue is equal to the complexity of the rest of the DAV specification
combined, we decided not to address this issue. But, since our properties
are marshalled using XML, it does raise the possibility that RDF can be used
as the format of WebDAV properties in a "plug and play" manner.
But, the WG has, on many occasions, decided not to address this issue.
>
> > Null Resource - A resource which responds with a 404 (Not Found) to
> > any HTTP/1.1 or DAV method except for PUT, MKCOL, OPTIONS and LOCK.
> > A NULL resource MUST NOT appear as a member of its parent
> > collection.
>
> [CLARITY] Huh? I assume this has something to do with the
> gobbledygook in section 5.
*sigh* Originally, we only defined null resource in section 7.4 ("Write
Locks and Null Resources"). But then someone objected that the term wasn't
defined before it was used, and this might cause confusion. Thus we added
it to the terminology section. Judging from your reaction, people are still
being confused. Perhaps adding a forward reference to section 7.4 might
ease some confusion.
> > Participants of the 1996 Metadata II Workshop in Warwick, UK
> > [Lagoze, 1996], noted that "new metadata sets will develop as the
> > networked infrastructure matures" and "different communities will
> > propose, design, and be responsible for different types of
> > metadata."
>
> [CLARITY] This whole section (4.2) is weak.
> It is insufficient to merely quote some putative authority who
> once said something that might be interpreted to sanction your
> dismissal of antecedent work. Instead, there should at least
> be some adumbration of a critique.
In fact, within the Web community, the Dublin Core group are deemed to have
considerable authority, and are far from "putative". What basis do you have
for refuting the claim that the participants of the quoted workshop do not
have authority in the field of metadata?
Furthermore, in a section filled with informational references to other
metadata efforts, I don't see how you can claim we are "dismissing" this
previous work. Rather, we are acknowledging its existence, and, by
inference, its influence on our work.
Finally, I do not feel that a normative protocol specification representing
the consensus viewpoint of an entire community should have either a full
critique, or even an "adumbration" of a critique, since presumably some
members of the community would object to the opinions expressed in the
critique, and the critique would not contribute to the interoperability of
applications written using the protocol.
The only reason the section is in the draft at all is because we received
several emails from people who seemed to think that we were completely
ignorant of all existing metadata proposals -- by providing an enumeration
of current proposals, we were hoping avoid future exchanges.
> The question here isn't one of defining a new set of
> properties, it is one of defining a whole new framework
> for representing properties. (I suspect the quote above is
> really just in regards to the first question.)
Sorry to invoke the "Gates" defense here, but what exactly do you mean by a
"framework for representing properties." There are so many proposals, and
so many different ways of viewing this problem, I need more information
before I can tell what you mean. Furthermore, even if I did know exactly
what you mean, I'm not sure what bearing it has on the DAV specification.
> Proposals such as RDF are in *direct* conflict with this one.
Actually, after discussing the interaction of WebDAV properties and RDF with
Bob Schloss and Eric Miller at WWW7, with Ralph Swick in meetings at the
W3C, and with Guha in a Design Team meeting at Netscape, I wholeheartedly
disagree. Could you be more specific about how these proposals are in
direct conflict, since the people directly working on RDF don't share your
opinion?
> It would be as if the Dublin Core group decided not only
> on their 15 properties, but decided to go make up their
> own property representation as well (instead of using RDF).
> We need another property representation like a hole in the head
> (or like another style sheet proposal...).
>
> [OBJECTION] The property proposal here should be extracted
> and made to stand on its own, if it can. The property mechanism
> used is, or should be, orthogonal to the portent of the rest of
> the draft.
I'm assuming you mean "content", and not "portent".
> Properties are of general utility, beyond webdav.
> There are several emerging protocols, such as iCalendar, SWAP,
> and RVP (not to mention HTCPCP!) which have need for property
> syntax, manipulation ("PROPPATCH") and query ("PROPFIND").
> Regardless of your opinion of those example protocols, I hope
> you agree that it is neither necessary nor desirable to have
> a suite of contradictory property mechanisms specific to
> particular http extensions. In fact, webdav-versioning,
> ACP, and DASL -- all "in the family" -- have all three already
> found a need to extend the property proposal contained in
> webdav-protocol. It would be a worthwhile exercise to make
> that property proposal stand on its own just for the webdav
> program alone.
>
If other protocols wish to use WebDAV properties alone, then they can define
an appropriate subset of WebDAV capability, and mechanisms for discovering
that a server (presumably some extension to OPTIONS) supports that
capability. WebDAV does not preclude this -- text on compliance is limited
to a single section (15). We chose our compliance classes carefully to
ensure the least amount of possibile variation. We were *very* concerned
that by having multiple levels of compliance that we would dramatically
undermine interoperability. I am not at all in favor of introducing
another axis of optionality just to satisfy as yet hypothetical future
consumers of the specification. Let those future consumers figure it out.
> Getting beyond the requirements of other protocols, if we ever
> want to get to the point of allowing independent communities
> to define new property sets (as described in the quote above),
> we need to have the confidence that the property mechanism is
> sufficiently accommodating.
>
> A detailed comparison to other property framework proposals,
> outlining the pros and cons of different approaches, would
> also be worthwhile because however much thought has gone into
> the properties framework in webdav, more has gone into RDF and
> some of the other proposals.
Again, this sounds like it would be worthwhile information to have in a
WebDAV Design Document.
>
> It is as yet unclear whether RDF will "stick". While it is
> quite capable in expressive power, it is becoming ever more
> obtuse with every revision. Furthermore, RDF is to a large
> extent an unfulfilled promise in that as yet it has no more
> than intimated how properties will be maintained or queried
> over protocol. However, there does seem to be some force
> behind it. In particular, that great spawn of a protocol,
> P3P, may get accelerated for political reasons, and P3P relies
> on RDF.
>
> Regardless of who emerges the victor, I hope that there
> is only one. It makes no sense for authors, programmers,
> web server vendors, and client applications to all have
> to contend with multiple property protocols for essentially
> the same purpose.
This is why we made sure that WebDAV could accomodate RDF.
> The webdav-protocol draft could be written in a manner
> independent of the particular property framework,
> subject to some stated requirements from that service.
> This would allow the webdav protocol to be considered
> independently of the merits of the particular property
> framework to which it is currently joined at the hip, and
> would allow it to survive if for reasons political or
> technical some other property proposal ends up holding sway.
I have a hard time envisioning how this would work in an interoperable way.
Upgrading protocols while they are in use has been pretty hairy in the past.
> > The XML namespace mechanism, which is based on URIs [RFC2396], is
> > used to name properties because it prevents namespace collisions and
> > provides for varying degrees of administrative control.
>
> [CLARITY] So is a property name a URI or not?
> Can it have a URI associated with it, or is there just
> the URI associated with the entire namespace?
A property name is a URI, which is marshalled on the wire as an XML element
whose name is a compound of the base element name and the namespace name.
> > Finally, it is not possible to define the same property twice on a
> > single resource, as this would cause a collision in the resource's
> > property namespace.
>
> [CLARITY] Huh? LDAP can have multiple values for a single attribute
> (like "telephoneNumber") without that happening. Or maybe you mean
> something else?
No, we mean what we say. Multi-valued properties would look soemthinglike:
<V:widgets>
<V:widget>...</V:widget>
<V:widget>...</V:widget>
...
</V:widgets>
>
> >4.6 Media Independent Links
> > Although HTML resources support links to other resources, the Web
> > needs more general support for links between resources of any media
> > type. WebDAV provides such links. A WebDAV link is a special type
> > of property value, formally defined in section 12.4, that allows
> > typed connections to be established between resources of any media
> > type.
>
> [CLARITY] "Media type" was also mentioned in the introduction.
> What is this thing with "media"?
See previous explanation.
- Jim
Received on Monday, 23 November 1998 18:25:51 UTC