RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED

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

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Sunday, June 09, 2002 3:43 AM
...
> 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...

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.

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

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

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

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

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

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

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

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

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

Lisa

Received on Sunday, 9 June 2002 14:05:54 UTC