Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED

From: "Jason Crawford" <[email-masked]>
Date: Sat, 11 May 2002 13:11:07 -0400

<<
What is the interoperability mechanism?
I would prefer a source Link solution, myself, since that can be supplied
in a normal HTTP error response.
I like the source link solution also, but we have to demonstrate
interoperability.  People haven't been breaking down the doors for this and
no interoperability has been determined.  An additional proposal would have
to be made, and then implementations of that would be needed, and then
interoperability tested.  In the mean time the spec could not move forward
to the next stage.  But we have real important changes in store that are
already approved and time we spend on defining the DAV:source property,
which people haven't been requesting heavily, is time folks are
implementing 2518 with all it's warts instead of all the improvements we've
already approved.

<<
In my opinion, WebDAV needs to solve this issue before progressing on
the standards track.  It cannot simply remove it without abandoning the
pretense that it handles Web authoring.
My thinking is, we need to move the spec forward and dav:source isn't
something people have been requesting heavily.  I suspect the reason they
haven't is because it's not heavily needed.    Before WebDAV we've had file
system access and FTP access.  These were used pretty easily for authoring
without a source property.  Folks just knew what part of the FTP or file
system namespace needed to be accessed to do their editing.  It's not a
terrible burden to expect the same to happen with WebDAV.  Servers will
often provide a WebDAV enabled URI space to access underlying resources
(much like what is accessed in the file system or via FTP).   Down the
road, if there is a demand, we'll spec a new DAV:source property that
points to the source URL tree that many folks have already been using.

------------------------------------------
Phone: 914-784-7569,   [email-masked]

---

From: "Jason Crawford" <[email-masked]>
Date: Wed, 15 May 2002 12:53:12 -0400

> I'll implement this source-set proposal sometime this week hopefully,
> given that nobody else objects to using XLink.

Can we get a few more folks implementing it so we can test
interoperability?

---

From: "Clemm, Geoff" <[email-masked]>
Date: Tue, 28 May 2002 08:19:14 -0400

x1: I consider it significantly more important that
a WebDAV feature be consistent with the WebDAV standard than that it be
consistent with some other non-WebDAV standard, W3C or other.

x2: I consider it significantly more important that a WebDAV feature
be processable with standard WebDAV aware parsers (which expect href
elements) than that they be processable with a non-WebDAV parser (such
as XLink).

x3: I consider adding a DAV:role element to be a superior way of adding
this functionality in a WebDAV spec, given the capability of later
extending the DAV:role element with additional structured values, which
is not available with a role attribute.

h2: The DAV:expand-property report is just a concrete instance of the
cost of being inconsistent ... if we adopt the xlink:href attribute
for the DAV:source property, every WebDAV feature that wants to do something
generic with DAV:href elements would have to be defined and coded to look
for both DAV:href elements and xlink:href attributes.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Tuesday, May 28, 2002 3:11 AM
To: Clemm, Geoff; Webdav WG (E-mail)
Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Tuesday, May 28, 2002 2:44 AM
> To: Webdav WG (E-mail)
> Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED
>
>
> I agree with the addition of the DAV:sourcelabel element.
>
> But I object to the use of the xlink:href attribute, instead of the
> standard WebDAV DAV:href element.  I believe it is significantly more
> important to maintain consistency within the WebDAV standard than it
> is to be consistent with some non-WebDAV standard such as xlink.  In
> particular, this breaks functionality such as is provided by the
> DAV:expand-property report defined in RFC-3253, which is based on the
> existence of DAV:href nodes in property values.

Geoff,

I expected this one :-)

Pros for DAV:href syntax:

h1 - consistent with other WebDAV specs
h2 - can take advantage of DAV:expand-property report

Pros for XLink syntax:

x1 - consistent with W3C recommendations
x2 - can be processed using standard XLink aware code (for instance, in
browsers / xml based user interfaces)
x3 - provides a standard framework for the definition of rules as URIs

Thoughts:

h2: isn't really a problem. We just define a new REPORT (or extend the
existing one) to work on xlink:href elements as well. Note that xlink:href
elements may appear in other people's dead (and live) properties anyway, so
it makes sense to have a standard way to resolve them anyway. If there's
some interest in this, I'll make a proposal.

x3: I think any solution using non-XLink based syntax must define a way how
to express the role of the link. One way would be to reuse XLinks link role
URIs *without* using their syntax (which I'd consider lame :-).