Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED

From: "Julian Reschke" <[email-masked]>
Date: Sun, 9 Jun 2002 12:42:42 +0200

Lisa,

thanks for compiling this list of issues. I agree that we need to think
about them, but I'm not sure that we have to *solve* them all. Sometimes a
problem just is too complex to be solved completely in the first (or
actually, second) attempt, and it makes sense to concentrate on the subset
of issues that's simpler and well understood...

> From: Lisa Dusseault [mailto:[email-masked]]
> Sent: Sunday, June 09, 2002 2:20 AM
> To: 'Webdav WG (E-mail)'
> Cc: 'Julian Reschke'; 'Joe Orton'
> Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED
>
>
> I've been thinking more about the source property problem.  It's
> deeper than
> it looks.  Here are *some* of the problems, the things that are not
> specified.  More are sure to be found as we start answering the initial
> questions:
>
> 1. Must the resources pointed to by the SOURCE header be
> WebDAV-compatible?

a) What is the definition of a "WebDAV-compatible" resource? Being the
member of a WebDAV collection?

b) I'm tempted to say: no.

> 2. Must the source property point to ALL the files involved in
> producing the
> result?  Be careful here -- there could be data files as well as source
> code, libraries, build files, etc.

I don't think that's feasible.

> 3. When the source property points to multiple files, what role
> does each of
> them play?

The one defined in the role attribute (if present).

> 4. Clearly in order to get the source code for a dynamic resource, the
> client must do a GET to the URL(s) in the source header.  But what URL
> should the client send PUT to?  Does PROPFIND address the source
> code or the
> output?

Source and dynamic resources are different resources with separate URLs. All
HTTP/WebDAV methods operate on the respective request URLs.

See <http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm>,
section 6.2.3.

> 5. What does it mean when a dynamically-generated resource is the
> source for
> a COPY request?  Is it different when it's the source for a MOVE request?

I think that's open to discussion. For COPY, it seems it would make sense to
require that the newly created resource must behave as the original
resource, so it should still be a dynamic resource, and have the same source
links. MOVE obviously MUST move the resource -- and if this can't be done by
the server, the request must fail.

> 6. How does a client *create* dynamically-generated Web pages?
> Think of all
> the problems with that - where should the client upload new source files?
> How can the client specify what URL in the main repository is actually an
> invocation to handle this dynamic resource?

Right now I'd say that's server-specifc. Depending on how dynamic resources
are implemented, it's hard to see how there can be a generic way to author
them.

> 7. How does a client add a new source file to an existing set of source
> files?  E.g. assume I want to modify a JSP to call a new object in a new
> library.  That library is not on the server yet.  How do I upload
> it?  Where

Again, I think this is server-specific. The server may allow you to PUT the
file anywhere, or at a specific location. And of course a server may allow
PROPPATCH on the source-set property.

> to? How do I indicate to the server that it's a source file and not a
> content file?

What's the difference?

> 8. How do I configure the server's classpath?  How do I get it to compile?

Out of scope.

I agree that it would be interesting to see how the source-set property can
be applied to a Servlet engine, and to come up with interoperable ways to
author servlets...

> I don't think that Julian's proposal goes very far towards a complete
> solution.  As it stands, it addresses only part of #3, in that it
> provides a
> syntax for describing roles, though it does not specify what the
> roles are,
> which is clearly necessary for interoperable implementations. Moreover, it

Well. Please then enumerate all roles we'll need for interoperability. If
you think RFC2518+ needs to do this, we are free to assign names, qnames or
URIs to these roles and we are done. I personally don't think we should get
into that business (at least not now).

> creates a significant new dependency on XLink, a non-trivial
> specification.

I agree that XLink itself is non-trivial. But we depend only on a very small
subset of XLink (simple links), and not using this subset makes our own work
harder, not simpler (because we would have to duplicate the work done in
this recommendation).

For those who haven't looked at XLink, here's what we depend on:

- a well-defined namespace
- two attributes (role and href)

> In view of the problems that remain to be solved I don't think
> that XLink is
> bringing enough to the party to justify the additional complexity.

Could you please explain where you see *additional* complexity? Usually,
reusing existing methodology *simplifies* a specification.

Using the same line of argument one could say that using XML causes
additional complexity, and therefore WebDAV should have used a simpler
marshalling format.

> That said, instead of getting bogged down in syntax, I'd like to see us
> figure out what the abstract semantics of a new solution would be (see
> questions 1-8 above). Once we've got that stuff nailed down we can worry
> about how to encode it on the wire. In view of the complexity we already
> know about, I suspect this is going to turn out to be a
> significant project.

It depends on what we want.

a) Just fix the source property defined RFC2518 for inclusion in RFC2518bis?
That was my understanding.

b) Completely solve the problem of remote authoring? That's hard.

Julian

---

From: "Lisa Dusseault" <[email-masked]>
Date: Sat, 8 Jun 2002 17:20:06 -0700

I've been thinking more about the source property problem.  It's deeper than
it looks.  Here are *some* of the problems, the things that are not
specified.  More are sure to be found as we start answering the initial
questions:

1. Must the resources pointed to by the SOURCE header be WebDAV-compatible?

2. Must the source property point to ALL the files involved in producing the
result?  Be careful here -- there could be data files as well as source
code, libraries, build files, etc.

3. When the source property points to multiple files, what role does each of
them play?

4. Clearly in order to get the source code for a dynamic resource, the
client must do a GET to the URL(s) in the source header.  But what URL
should the client send PUT to?  Does PROPFIND address the source code or the
output?

5. What does it mean when a dynamically-generated resource is the source for
a COPY request?  Is it different when it's the source for a MOVE request?

6. How does a client *create* dynamically-generated Web pages? Think of all
the problems with that - where should the client upload new source files?
How can the client specify what URL in the main repository is actually an
invocation to handle this dynamic resource?

7. How does a client add a new source file to an existing set of source
files?  E.g. assume I want to modify a JSP to call a new object in a new
library.  That library is not on the server yet.  How do I upload it?  Where
to? How do I indicate to the server that it's a source file and not a
content file?

I don't think that Julian's proposal goes very far towards a complete
solution.  As it stands, it addresses only part of #3, in that it provides a
syntax for describing roles, though it does not specify what the roles are,
which is clearly necessary for interoperable implementations. Moreover, it
creates a significant new dependency on XLink, a non-trivial specification.
In view of the problems that remain to be solved I don't think that XLink is
bringing enough to the party to justify the additional complexity.

know about, I suspect this is going to turn out to be a significant project.

Lisa

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Julian Reschke
> Sent: Wednesday, May 15, 2002 3:53 AM
> To: Joe Orton; Webdav WG (E-mail)
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Joe Orton
> > Sent: Wednesday, May 15, 2002 12:32 PM
> > To: Webdav WG (E-mail)
> > Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED
> >
> >
> > On Wed, May 15, 2002 at 01:19:00AM +0200, Julian Reschke wrote:
> > > > I just thought it was unnecessary to have to depend on
> yet another
> > > > specification for something this simple.
> > >
> > > 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.
> >
> > 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.
>
> OK, I'll try to come up with the right wording.
>
> > ...
> > > 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.
> >
> > 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.
>
> 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?
>
> > I'll implement this source-set proposal sometime this week
> hopefully,
> > given that nobody else objects to using XLink.
>
> Sounds great.
>

---

From: "Lisa Dusseault" <[email-masked]>
Date: Sun, 9 Jun 2002 11:06:26 -0700

I think I can explain some of my concerns better in response...

> From: Julian Reschke [mailto:[email-masked]]
> Sent: Sunday, June 09, 2002 3:43 AM
...
> all. Sometimes a

That's true.  A list of agreed requirements might be a good start here.  It
seems to me that the point of the exercise is to specify a standard to allow
clients to interoperably author dynamic content as well as static content.
These questions are intended to address what I consider the minimal feature
set required to author dynamic content. If implementors have to invent
private extensions to get these features then it's not clear why we bother
specifying anything along these lines at all.

> b) I'm tempted to say: no.

If an OPTIONS response for the resource includes the DAV: header with level
1 or 2 support, it's a WebDAV resource.  If the answer is "no it's not a
WebDAV resource", then how is authoring of the dynamic content possible?

> I don't think that's feasible.

If it's not possible to view and edit or replace all the files involved in
producing the result, then how is it possible to authoring dynamic content?

> HTTP/WebDAV methods operate on the respective request URLs.

Compare with the next question/answer to see the inconsistency with this
position.

> the server, the request must fail.

All right, now we see the inconsistency.  Say we have a dynamic resource,
"foo", and the server reports that there's only one source file,
"foo-source".

If all methods operate on the respective request URIs, that means that a
COPY request to foo must operate on the dynamically-generated content, not
the source.  So wouldn't that mean that a snapshot of foo is copied to the
destination?  It wouldn't be a dynamic resource.  Fair enough. Presumably we
can COPY foo-source to get a second dynamic resource.  But what happens if
you MOVE foo?  Does it operate only on a snapshot of the dynamic resource?
What does that mean?

> PROPPATCH on the source-set property.

Seems to me both 6 and 7 are essential features.  I don't understand how
authoring dynamic content is supposed to work unless we offer them.

> > to? How do I indicate to the server that it's a source file

A new source file is a new file which will be interpreted or compiled by the
server in order to produce dynamic content.  By "content file" I meant
static Web page, or regular resource.  How can the client create a new
source file and let the server know it's supposed to interpret or compile
it?

> into that business (at least not now).

If we don't specify roles then we've got a framework, not a protocol and the
result will be that every server will define their own set of roles that
each client will have to know about, which is an interoperability disaster.
I agree that for the WG to specify a set of roles is a non-trivial problem,
but that's what's required for a standard.

> reusing existing methodology *simplifies* a specification.

The idea isn't primarily to simplify the specification but rather to make
the implementor's life easier. With some modest additional effort we could
invent something that would be vastly simpler for the implementor to grok
and not require a dependency on some other specification.

> additional complexity, and therefore WebDAV should have used a simpler

As always, there's a balance between the benefits of not having to reinvent
something and the additional complexity of importing something that wasn't
designed for the specific purpose you're using it for. In my view, using XML
falls on one side of this line and XLink on the other.

> That was my understanding.
What "fix" means depends on what you think is broken. It's not clear to me
why you think that the only thing that's broken is that there's no way to
communicate roles. And if that is what's broken, I don't understand why you
think having a placeholder for private roles does the job.

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Sun, 9 Jun 2002 21:01:05 +0200

> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Sunday, June 09, 2002 8:06 PM
> To: 'Julian Reschke'; 'Webdav WG (E-mail)'
> ..

I fear this isn't a definition at all. RFC2518 says that upon OPTIONS, the
DAV header must be returned for WebDAV compliant resources. It does NOT
define what a WebDAV compliant resource actually is (isn't this on our
issues list)?

So if your question was: "must every source resource report the DAV header
upon OPTIONS?", I'd say: no. I'm not even sure I'd require that it must be
an HTTP resource.

> producing the result, then how is it possible to authoring

It may not be possible. It may not be necessary.

Take a simple example: we've got a dynamic resource that depends on an XML
source file and an XSLT transformation. Only the the XML source file is
available for direct editing, the XSLT is not. Why would this be a scenario
that shouldn't be supported?

> Compare with the next question/answer to see the inconsistency with this

I don't think this is inconsistent or something that can be negotiated. This
is the nature of the HTTP protocol.

> COPY request to foo must operate on the dynamically-generated content, not

No. It must operate on the request URL, thus on the dynamic *resource*, not
it's content.

> destination?  It wouldn't be a dynamic resource.  Fair enough.

No, I don't think this is what it means.

> Presumably we

MOVE moves the resource. If it's a dynamic resource, so it must be after the
MOVE. If this isn't possible, the MOVE MUST fail.

> authoring dynamic content is supposed to work unless we offer them.

I don't see how you can achieve this. There are so many ways to
setup/program servers to generate dynamic resources (ASP, PHP, CGI, Cocoon,
Servlets, ...), how can a single protocol define a *generic* way to set them
up? I strongly disagree that we need to solve this problem (now).

> source file and let the server know it's supposed to interpret or compile

I still don't see the difference. Being the source of a link isn't anything
special for a resource.

Is setting up new dynamic resources a desirable feature for remote
authoring? Yes. Does it need to be resolved in terms of the source-set
property? I don't think so.

> but that's what's required for a standard.

I strongly disagree. In fact, I'd say that the WebDAV should not attempt to
define these roles. What these roles are heavily depends on the type of your
server, and there's no way how we can define every conceivable role.

> and not require a dependency on some other specification.

OK, every implementor already has to have understood the mechanics of
xml:lang, right? I just don't understand why you consider it a problem to
understand the two new attributes xlink:href or xlink:role as well? Details,
please.

> designed for the specific purpose you're using it for. In my

It was *exactly* defined for this purpose: to specify links to other
resources and to augment them with additional information.

> view, using XML

What I think is broken is:

1) the wording and the examples in RFC2518,

2) the fact that there's no standard place to specify a role,

3) that a client doesn't have any useful information that would allow it to
classify/label the various links.

My proposal adresses all these issues. In particular, a client will always
be able to label the role, even if xlink:role isn't present or not
recognized (because there's a human-readable label for the role).

I think the requirement for an exhaustive list of roles essentially makes
this protocol feature impossible to specify. So again: are we trying to
revise the source property for RFC2518bis, or are we talking about something
for later specs? In the former case, I think we have all we need.

Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 12 Jun 2002 13:04:35 -0700

> WebDAV resource", then how is authoring of the dynamic content possible?

That is not relevant.  The resources might just as easily be ftp or file 
URLs,
or might only be authorable by someone with authorization or coming from
a particular IP address.  Identifying the source does not imply 
authorability
on that resource, nor does it need to in order to be useful to the user.

>>> producing the result?  Be careful here -- there could be data files as
>> well as source

How is it possible to author an e-mail message when some of the message
header fields are generated?  That question is simply not relevant to
the issue of identifying the source of dynamic content when the server
does have a URI for that content.

>>> code or the output?

They are different resources.  The effects of a particular method on any
particular resource are defined by that resource.  The source for one
resource may itself be a dynamic content resource with its own source URI.

>>> a COPY request?  Is it different when it's the source for a MOVE 

If that isn't already defined by RFC 2518, then it isn't defined for any
resource.  There is no distinction on the Web between dynamic and static
content.

> you MOVE foo?  Does it operate only on a snapshot of the dynamic resource?

Why is this confusing?  If a resource does not allow COPY, then it would
not respond to COPY with 200.  There is no magic being done behind the
curtains.  What does COPY mean for RFC 2518?  It means the same thing for
both dynamic and generated resource -- there is no difference between the
two.  Some resources will simply not allow COPY or MOVE.  That is why it
is NECESSARY to point to the source of the resources, since those other
resources are the ones that usually can be copied or moved.

>> are implemented, it's hard to see how there can be a generic way to 

There are many ways in which a namespace can be constructed on a server.
The user creating a service generally knows what they are doing or are
following the instructions provided to them by the server owner.

> authoring dynamic content is supposed to work unless we offer them.

The degree to which the server's implementation space is itself a WebDAV-
enabled name space is dependent on the particular site configuration and
none of our business.  If they are authorable, the user will be able to
author them.  There is no need, nor any desire, for such security-sensitive
activities to be automatically handled by authoring tools.

> source file and let the server know it's supposed to interpret or compile

The server will either already know how to interpret its name space or
the client will author (via another URL) the appropriate configuration
or binding needed to enable the dynamic resource.

....Roy