RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Sunday, June 09, 2002 8:06 PM
> To: 'Julian Reschke'; 'Webdav WG (E-mail)'
> Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED
>
>
>
> I think I can explain some of my concerns better in response...
>
> ..
>
> > > 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.
>
> 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 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.

> > > 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.
>
> 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?

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?

> > > 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.
>
> Compare with the next question/answer to see the inconsistency with this
> position.

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

> > > 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.
>
> 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

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

> 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.

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

> 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?

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.

> > > 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.
>
> 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.

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).

> > > to? How do I indicate to the server that it's a source file
> > and not a
> > > content file?
> >
> > What's the difference?
>
> 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?

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.

> > > 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).
>
> 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.

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.

> > > 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.
>
> 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.

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.

> > 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.
>
> 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

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

> view, using XML
> falls on one side of this line and XLink on the other.
>
> > It depends on what we want.
> >
> > a) Just fix the source property defined RFC2518 for inclusion
> > in RFC2518bis?
> > 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.

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

Received on Sunday, 9 June 2002 15:01:49 UTC