RE: [Mathias.Picker@virtual-earth.de: Re: [Interop] quick poll on the Translate field]

   From: Mathias.Picker@virtual-earth.de

   I'm not against the source paradigm, but still see some problems
   there.  The very first thing being the completely undefined
   semantics of it, if it has more than one link per resource.

How is the semantics undefined?  If you have multiple resources that
are used to generate another resource, you need to give the user the
option to modify any of them, since only the user knows which one
needs to be modified.  It's no harder for the user to decide which
resource needs to be modified than it is to decide which line of a
resource needs to be modified.

   On  5 Nov, Clemm, Geoff wrote:
   > My standard response to everyone who suggests that it is
   > too complicated for a client to make sense of multiple source
   > fields is: adopt the convention that the first link is the
   > most important one, and just show that one.

   I do not think that conventions will solve this problem. If you think
   its the solution, bring it into the standard. 

I'm not sure what "problem" you are trying to solve.  The notion
of "most important" is going to be a fuzzy concept at best, so
you won't be able to formally define it in any case.

   Actually, I don't think it's a solution. When we put that  information
   into the standard, we should a t least formally model this decision, by
   honoring the "preferred", "true", "i-really-mean-this" link with special
   markup. And here we have the semantic problem again: what do we _mean_
   with multiple source links, and which one ist the "true" link to the
   source of this property?

The whole point is that when there are multiple sources, there never
is a well defined notion of "preferred", "true", or any such thing.
Just as there is no well defined notion of "the preferred line of the
file to change" or "the preferred paragraph to change".

   This is a bit like a file system, which does not show me mysource.c, but
   mysource.h, someheader.h, somesystemheader.h, evenmoreheaders.h,
   someconnectedsource.c,, mysource.c, somelibrary.a,
   somethingsentirelydiffent.dontknow. 
   Do you find the source in that? Would you _want_ your file system to do
   that? And that's pretty much the example from the standard.

If the thing I had to fix was defined in mysource.h, and not in
mysource.c, a client that only showed me mysource.c is pretty useless.
The difference between "test.c", "test.exe", and "the output of running
test.exe" are all significant, and should each have their own URL.

   > One very common mechanism for doing Web-based access control
   > is to base the access control on the URL (i.e. what you can do
   > to a resource depends on what the URL is).  Using any header
   > (such as the Translate header) breaks any scheme like this.

   Good point. But we do not control acces by URL, we control it by URL and
   method, and since some header obviously modify the semantic of methods
   (e.g. GET with if-modified-since is really a HEAD (=PROPGET?) if the
   resource has not been modified), so we allready control by URL and
   method and header implicitly,  why shouldn't we officially control by
   URL and method and header?

A header is an "argument" to a method.  Normally, you do not base
your access control for a method on the arguments to the method.
Obviously you could in theory, but in practice the cost outweighs
the benefit.

   > When you do a COPY, should it go against the raw form or
   > the processed form of the resource?  Probably need the Translate
   > header for that then too.  Similarly for any other method that
   > could reasonably be applied to both the raw and the processed form.

   Yes, and that's perfectly fine. Where's the problem there?

The problem is that "Translate" is only one of many headers that
one could think of that redirect to different content (e.g. a
Version-Selector header for versioning, and a Variant-Selector
header for variants.  This means that every method would need
to contain the logic for all of these headers, which requires
massive reworking of the implementation whenever such a header
is introduced.  In addition, you now you have to define what happens
when you combine these headers (is that the "Translate" of the
"Version-Selector", or vica versa).

   Compare this
   to the source solution:

   Just look at the example in 13.10.1, where foo.bar/program has three
   source links. How do you copy this?

Only the user knows the answer here, since it depends on what is being
done.  The copy operation needs to be well defined, and then the user
can make sensible choices on composite copy requests.

   And, how do you manage the
   connection source to destination? I mean, if I copy the source or
   destination, should the corresponding destination or source be copied
   with it?   If I copy the destination, will I create a sort of "binding",
   since in effect it's the same as the first destination, since it uses
   the same source link? or do I need to copy the source link, too? What
   happens if I move one or the other?

It depends.  There is no right answer here, so forcing one as the
only answer is wrong.

   Nothing of this is defined (I just tried to find it in the standard or
   in the issues list, correct me if I'm wrong), making the current
   solution, well, hmmmm, what can I say ...: unusable? 

Nothing of this is defined because there is no "right" answer.
Forcing a trivial wrong answer does not help things.

   > So all that is needed is for the server to be able to dummy up
   > some URL that means "the raw form of this resource" to avoid all
   > these issues.  That does not seem like an unreasonable burden on
   > the server implementor.  Similarly, I don't think it is an
   > unreasonable burden on a client writer to do one extra roundtrip to
   > retrieve a tree of source images (i.e. one Depth:infinity PROPFIND to
   > retrieve all the links for a tree).

   Well, unreasonable burden for the developer or not, I want the source
   and dest links to be the same, so users can use their favorite
   html/text-editor to edit the page and include links that actually work,
   whithout thinking about where the link should go, e.g. source or
   destination. Different source and destination hierarchy place an
   unreasonable burden on the _user_, not on the developer.

Well, I want my users to be able to modify the right line of the
source file without thinking about which line they need to modify.
I won't get that either (:-).

Cheers,
Geoff

Received on Tuesday, 6 November 2001 12:36:37 UTC