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?

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?

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

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.

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.

Lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke
> Sent: Wednesday, May 15, 2002 3:53 AM
> To: Joe Orton; Webdav WG (E-mail)
> Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED
>
>
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]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.
>

Received on Saturday, 8 June 2002 20:19:29 UTC