Subject: Issue: SOURCE_PROPERTY_UNDERSPECIFIED

From: "Jason Crawford" <[email-masked]>
Date: Thu, 9 May 2002 18:51:38 -0400

One of the issues Lisa brought up below was not covered in subsequent
discussions.  That issue was what to do about the source property.

In fhe following recent post

http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0351.html

It was indicated that at the IETF meeting there was a proposal to drop the
source property.  Julian added that we can pick it up in the next version
of WebDAV.

I'd like to mark it resolved that we will remove the source property.  I
would leave it up to our memories to bring the topic up again in the next
version of WebDAV if we value it.

The thinking is...

The source property is good.
But it's under specified and needs work, no interoperability has been
determined, and no one has been yelling for it.  If we remove it from the
spec now, the few implementations that support it can remove that support
and thus provide us a clean slate to work from when we take another stab at
the source property.

Please speak up if you disagree with this or would like to add to what I've
said.

Thanks :-)

J.

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

                      "Lisa Dusseault"                                                                               
                      <ldusseault@xytho        To:       "Webdav WG (E-mail)" <[email-masked]>                
                      s.com>                   cc:                                                                   
                      Sent by:                 Subject:  54th IETF Meeting Information, and RFC2518 open issues      
                      w3c-dist-auth-req                                                                              
                      [email-masked]                                                                                    

                      04/22/2002 12:36                                                                               
                      PM                                                                                             

If you're not on the IETF-Announce list, you might not have seen this
announcement about the upcoming meeting in Yokohama.

To bring our "agenda" up-to-date, here's what I think the largest and
hardest issues are for RFC2518 bis:
 - Whether/how to change the If header rules and syntax
 - Whether/how to change the source property definition

Although the If header has been shown to be interoperable in its simplest
form with locktokens, it hasn't been shown to be interoperable in its more
advanced forms or with ETags.  The source property has not had any
demonstrated interoperability to my knowledge.

I'd like to encourage anybody with ideas on what to do with either of these
two features to make concrete proposals to the list.  If your proposal is
"leave things the way they are", I'd like to see some discussion on how to
meet the requirements for going to proposed standard (how to demonstrate
interoperability, and how much interoperability is enough).

Another ACL draft is expected before the Yokohama cut-off, therefore ACLs
will probably also be discussed in Yokohama.  I'll be asking for a meeting
slot.

Lisa

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of [email-masked]
Sent: Thursday, April 18, 2002 8:42 AM
To: IETF-Announce:
Subject: 54th IETF Meeting Information

Registration for the 54th IETF is now open.
Information can be found on the IETF web site at:
http://www.ietf.org/meetings/IETF-54.html

MEETING SITE:
Pacifico Yokohama Convention Center
1-1-1 Minato Mirai, Nishi-ku, Yokohama 220-0012 Japan
Tel: + 81 (45) 221-2112
Fax: + 81 (45) 221-2136

HOTEL ACCOMMODATIONS:
Information is available on
http://www.e-side.co.jp/ietf54/accommodation.html.
Please be advised that ONLINE RESERVATIONS will be available after April
22nd.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 10 May 2002 19:17:22 -0700

> and thus provide us a clean slate to work from when we take another stab 

If the source property is removed, then how will the server respond to a
client that attempts to use DAV on a resource that is not DAV authorable
but is derived from other sources?  What is the interoperability mechanism?
I would prefer a source Link solution, myself, since that can be supplied
in a normal HTTP error response.

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.

Cheers,

Roy T. Fielding, Chairman, The Apache Software Foundation
                  ([email-masked])  <http://www.apache.org/>

                  Chief Scientist, Day Software
                  2 Corporate Plaza, Suite 150
                  Newport Beach, CA 92660-7929   fax:+1.949.644.5064
                  ([email-masked]) <http://www.day.com/>

---

From: "Julian Reschke" <[email-masked]>
Date: Sat, 11 May 2002 17:48:31 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Roy T. Fielding
> Sent: Saturday, May 11, 2002 4:17 AM
> To: Jason Crawford
> Cc: Lisa Dusseault; Webdav WG (E-mail)
> Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED
>
>
> > and thus provide us a clean slate to work from when we take
> another stab
> > at
> > the source property.
>

I would assume that all authoring-type requests (PUT, PROPPATCH) will fail
(403?).

The issue that we have to resolve is that RFC2518 *does* specify a property
that signals source resources, however the mechanism is underspecified, and
because of that (and other reasons) we don't have interoperable
implementations of it.

For RFC2518 to move forward, it will either prove interoperability, or drop
the feature.

My suggestion is to drop {DAV:}source in RFC2518, then to define a new live
property in a separate RFC (this wouldn't block RFC2518's progress).

> in a normal HTTP error response.

So you'd prefer it to my an HTTP response header? We'd still need a PROPFIND
compatible live property that a user agent can use to discover the source
directly (without having to try to modify the resource).

> pretense that it handles Web authoring.

I don't think I can agree here. RFC2518 has proven useful without anybody
supporting this property, so it's current state shouldn't block any progress
on RFC2518.

---

From: "Julian Reschke" <[email-masked]>
Date: Sat, 11 May 2002 18:05:56 +0200

Hi,

I'm tempted to start a document that defines RFC3253-style QNames for the
preconditions/postcondtions that can cause a 403 or 409 to be returned in
RFC2518. Is anybody interested to collaborate on this?

Julian

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 13 May 2002 09:31:33 -0700

Roy Fielding writes:
> In my opinion, WebDAV needs to solve this issue before progressing
> on the standards track.

I agree. Authoring access to an unprocessed source representation of a
resource has been a WebDAV goal from the very beginning (see Section 5.5 of
RFC 2291). Removing RFC 2518's mechanism for accomplishing this doesn't help
reach the goal -- it's just a punt.

Jason Crawford writes:
> But it's under specified and needs work, no interoperability
> has been determined, and no one has been yelling for it.

Julian Reschke writes:
> The issue that we have to resolve is that RFC2518 *does* specify
> a property that signals source resources, however the mechanism
> is underspecified, and because of that (and other reasons) we
> don't have interoperable implementations of it.

In what way(s) is this mechanism underspecified? From my perspective, it
provides sufficient information for an authoring client to discover a URL
where authoring can take place.

I assert that, given a few weeks of coding, we could easily demonstrate at
least two clients and two servers interoperating on this feature as
currently specified. There are no obvious technical impediments to doing so.

- Jim

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 13 May 2002 18:46:49 +0200

> [mailto:[email-masked]]On Behalf Of Jim Whitehead
> Sent: Monday, May 13, 2002 6:32 PM
> To: Roy T. Fielding
> Cc: Webdav WG (E-mail)
> Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED
>
>
> Roy Fielding writes:

The main issues are that

- the text and examples in the RFC just do not make sense to me (see [1])

- the source property doesn't offer enough information to display
information about the *types* of link relations

[1] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0119.html>

> currently specified. There are no obvious technical impediments

Do you have specific servers and clients in mind?

---

From: Joe Orton <[email-masked]>
Date: Mon, 13 May 2002 20:50:48 +0100

> [1] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0119.html>

If you drop the XLink stuff I support the "source-set" property
described in that message as a replacement for the source property; I
implemented it a while ago for mod_dav and cadaver and it very works
nicely. (I started off implementing {DAV:}source but it suffers greatly
because of the two issues given above)

An alternative would be to retain the "source" property but drop the
redundant "src" element and replace it with a "description" element
giving a human-readable description of the link as the cdata content.

joe

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 14 May 2002 00:15:24 +0200

> [mailto:[email-masked]]On Behalf Of Joe Orton
> Sent: Monday, May 13, 2002 9:51 PM
> To: Webdav WG (E-mail)
> > [1]
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0119.html>
>

Joe,

I'm happy to have a different format (I've got enough flak promoting
XLink-compatible syntax :-). My requirements are

- must support multiple links
- there must be a machine-readable description for the link type
- the should be a human-readable description for the link type

Please post what you're using right now -- we'll probably able to extend if
necessary.

Julian

---

From: Joe Orton <[email-masked]>
Date: Mon, 13 May 2002 23:46:50 +0100

> Please post what you're using right now -- we'll probably able to extend if

I just dropped the xlink: from the href attribute, and got rid of the
xlink:role attribute entirely, giving e.g.:

<D:prop>
 <D:source-set>
  <D:source href="http://example.com/dav/source.xml">Source</D:source>
  <D:source href="http://example.com/dav/render.xsl">Stylesheet</D:source>
  <D:source href="http://example.com/dav/etc.etc"/>
 </D:source-set>
</D:prop>

which should satisfy your first and third requirements; I'm not sure
about "machine-readable" link descriptions being mandatory. My client
doesn't need to understand anything about the link, I just want it to be
able to display a menu of "URI: description" choices when there is >1
source available, so that the user can decide.

(Similarly, the minimum amount of server configuration I'd like to
require is saying e.g. "/dav/render.xsl is a source of /dav/*.xml")

Regards,

joe

---

From: Elias Sinderson <[email-masked]>
Date: Mon, 13 May 2002 15:59:29 -0700

I should think that what you have is machine readable as well, or am I missing
some critical bit here? If the specification says to provide a
RFC XXXX compliant URI for the source link, as below, I will bet that my machine
(read client software) can read it with little extra effort.

Elias

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 14 May 2002 01:08:03 +0200

The point is that is should be possible for the client to display the *type*
of the link without having to look at the human-readable description. It's
fine if this is optional. IMHO it's not ok if there's no standard way to do
this.

> [mailto:[email-masked]]On Behalf Of Elias Sinderson
> Sent: Tuesday, May 14, 2002 12:59 AM
> To: Webdav WG (E-mail)
> >   <D:source
> href="http://example.com/dav/render.xsl">Stylesheet</D:source>

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 13 May 2002 16:55:38 -0700

>   <D:source href="http://example.com/dav/etc.etc"/>

I like this, except for the "Source" and "Stylesheet" not being individual
elements or attributes. The i18n characteristics of the approach above are
not great -- I can just see a Kanji UI popping up a pick list of English
words, ugh. What was the perceived problem with using the xlink:role
attribute (and Xlink syntax in general?)

- Jim

---

From: Joe Orton <[email-masked]>
Date: Tue, 14 May 2002 21:41:02 +0100

> attribute (and Xlink syntax in general?)

I just thought it was unnecessary to have to depend on yet another
specification for something this simple.

An alternative proposal:

 <D:prop>
  <D:source>
   <D:link>
    <D:href>http://example.com/dav/source.xml</D:href>
    <D:description>Source</D:href>
   </D:link>
   <D:link>
    <D:href>http://example.com/dav/render.xsl</D:href>
    <D:description>Stylesheet</D:href>
   </D:link>
  </D:source>
 </D:prop>

where the href is mandatory, description is optional; this is i18n
friendly... any problems with this approach?

joe

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 15 May 2002 01:19:00 +0200

> Sent: Tuesday, May 14, 2002 10:41 PM
> To: Webdav WG (E-mail)

What do you mean by "depend"? We just reuse two standard attribute names
(xlink:href and xlink:role). That's what XLink is for -- if every
spec/document/protocol designer would take this position, it wouldn't make
any sense to try to come up with common vocabularies for this.

> friendly... any problems with this approach?

It's as i18n friendly as all the other proposals, and still lacks a
machine-readable way to represent the type of a link.

So again, why not just use the Xlink [1] compatible syntax that I proposed
back in October [2]:

   <D:prop xmlns:D="DAV:" xmlns:xlink="http://www.w3.org/1999/xlink">
     <D:source-set>
          <D:source xlink:href="http://foo.bar/src/main.c"
xlink:role="UriDescribingTheRole" xml:lang="en">source file</D:source>
          <D:source xlink:href="http://foo.bar/src/main.lib"
xlink:role="UriDescribingTheRole" xml:lang="en">library file</D:source>
          <D:source xlink:href="http://foo.bar/src/makefile"
xlink:role="UriDescribingTheRole" xml:lang="en">makefile</D:source>
     </D:source-set>
   </D:prop>

What's wrong with it? It fulfills all requirements and uses W3C specs where
applicable.

(Note that xlink:role would be optional, and xml:lang would just need to be
in scope somewhere, just as everywhere else in WebDAV land).

[1] <http://www.w3.org/TR/xlink/>
[2] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0119.html>

---

From: Joe Orton <[email-masked]>
Date: Wed, 15 May 2002 11:31:32 +0100

> any sense to try to come up with common vocabularies for this.

I just mean it's annoying to have to go and read Yet Another XSpec to
find out how to implement WebDAV.  If the DAV spec can explain that the
xlink:href attribute must contain a URI-reference, and that xlink:role
is entirely optional, then it's not really a problem.

...
> What's wrong with it? It fulfills all requirements and uses W3C specs where

It does mean requiring that clients resolve XML namespaces on attribute
names, which hasn't be necessary so far to implement a DAV client (in my
experience anyway); possible interoperability issues there.

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

joe

---

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 15 May 2002 13:19:02 -0700

> given that nobody else objects to using XLink.

In this case I think we should be compatible with the XLink syntax. As
members of the broader community of Web standards developers, we should be
consistent with existing relevant standards, unless we have a strong reason
for deviating.

Since most clients do not currently support the source property, I suspect
the interoperability issues won't be very significant.

- Jim

PS - I can't wait until Yaron sees we have added another XML attribute into
the DAV spec :-)

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 14 May 2002 02:31:15 +0200

> Sent: Tuesday, May 14, 2002 1:56 AM
> To: Webdav WG (E-mail)

Why is that a problem?

> words, ugh. What was the perceived problem with using the xlink:role

I think Joe's example is just missing the statement that the human-readable
text needs to be qualified with xml:lang *somewhere* in scope.

> attribute (and Xlink syntax in general?)

That I'd like to know as well.

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 15 May 2002 12:52:41 +0200

> Sent: Wednesday, May 15, 2002 12:32 PM
> To: Webdav WG (E-mail)

OK, I'll try to come up with the right wording.

> experience anyway); possible interoperability issues there.

A DAV client *must* use an XML namespace aware parser anyway. Do you say
that there are parser that do support namespaces on elements, but don't on
attributes?

> given that nobody else objects to using XLink.

Sounds great.

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 14 May 2002 01:03:51 +0200

Joe,

- the point of a machine-readable link type is that a client may be able to
offer a better user interface if it knows what kind of link this is. For
instance, there might be a special "role" for the XSLT file used for
creating an HTML presentation of an XML file, and certainly it would be good
for client to be able to detect whether one of the sources plays this role.
No, we don't have  to define roles, but it certainly makes sense to have an
optional place where they *may* be reported. XLink reports them using URIs,
and I think so should we.

- you have removed the XLink compatible syntax without, but have stayed with
the href attribute. This makes your format both incompatible with XLink and
the standard DAV:href format (which can be used by RFC3253's expand-property
REPORT). Why did you do this? It doesn't make your format simple to
process -- it just saves a few characters in the XML representation. I think
HREFs should either be reported consistent with other WebDAV standards
(DAV:href, supported by the expand-property REPORT), or compatible with
XLink (which I would personally prefer). Unfortunately, we can't have both
at the same time...

Julian

> Sent: Tuesday, May 14, 2002 12:47 AM
> To: Webdav WG (E-mail)