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

Our server currently supports the Translate header (because it's supported
by Microsoft). However, experience shows that the way it's defined (or not
defined, lacking any official documentation) I really problematic.

For instance, PROPFIND currently will behave differently depending on the
Translate header -- in the default case, the server will (try to) report the
properties of the dynamic content (and in many case will fail to do so, for
instance for the content length). This basically means that we're forcing
clients to supply a proprietary and under-specified header to get at the
'real'  (static) information.

It seems that having different URLs for different things is the way to go,
however, the DAV:source property should

a) have better documentation,

b) be easier to act upon by a user client (see proposal in [1])

Julian

[1] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0119.html>




> -----Original Message-----
> From: interop-admin@webdav.org [mailto:interop-admin@webdav.org]On
> Behalf Of Clemm, Geoff
> Sent: Monday, November 05, 2001 10:26 PM
> To: interop@webdav.org
> Cc: w3c-dist-auth@w3.org; Mathias.Picker@virtual-earth.de
> Subject: RE: [Mathias.Picker@virtual-earth.de: Re: [Interop] quick poll
> on the Translate field]
>
>
> 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.
>
> Some of the points made in the WebDAV thread against using
> headers to control what GET does:
>
> 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.
>
> 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.
>
> 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).
>
> Cheers,
> Geoff
>
>
> -----Original Message-----
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Monday, November 05, 2001 2:35 PM
> To: interop@webdav.org
> Cc: w3c-dist-auth@w3.org; Mathias.Picker@virtual-earth.de
> Subject: [Mathias.Picker@virtual-earth.de: Re: [Interop] quick poll on
> the Translate field]
>
>
> Mathias sent this directly to me. I believe it was intended to go back to
> the list. I've CC'd the main DAV list since this is turning from a quick
> poll about interop into a discussion of approaches.
>
> Cheers,
> -g
>
> ----- Forwarded message from Mathias.Picker@virtual-earth.de -----
>
> From: Mathias.Picker@virtual-earth.de
> Subject: Re: [Interop] quick poll on the Translate field
> To: gstein@lyra.org
> Date: Mon, 5 Nov 2001 12:12:15 +0100 (CET)
>
> SimpleCMS does support it, as well as the source/link way of doing it.
>
>
> On  3 Nov, Greg Stein wrote:
> > On Fri, Nov 02, 2001 at 05:33:17PM -0800, Matthieu Chevrier wrote:
> >>...
> >> --> which WebDAV Servers and Clients support (or will very soon) the
> >> 'Translate' field ? (besides IE on PC)
> >
> > mod_dav does not implement it, and it never will.
> >
> >
> > IMO, it is the wrong approach to solving the problem. The source/link
> > stuff and multiple resources is the right way. You didn't ask for a
>
> No, it isn't. translate and source/link solve different problems. WebDAV
> emulates a file system layer. So my clients expect _one_ source file.
> Everthing else is nice-to-have, and may be very powerfull for some uses,
> but is obviously wrong for a simple: give me _this_ resource,
> untranslated.
>
> As for SimpleCMS, we could well use the both approaches for different
> reasons (we do not right now).
>
> Situation: every page is transformed on-the-fly, using a menu-module,
> and possible background, logo etc. resources.
>
> So, where should the source link(s) point to? The complete solution:
> - a raw version of the url in question
> and probably
> - a menu vonfig page, where the current menu style is choosen (or the
>   menu program module??)
> - the background gif
> - the logo, if used
> - any sub-dir logos, if used
> - possible many more resources.
> - if it's a database generated pag: possible pointers to the raw table
>   data, too.
>
> Very powerfull, potentially very usefull, but tell me: how should a
> network redirector like WebIFS show this mess to the user??
>
>
> Instead, the translate header would just say: give me _this_ url,
> untranslated. No questions what this means. One resource. No choice (no
> power, too :). Easy to realize, consistent with the file system model,
> and easy to explain to the user.
>
> So: source link are nice and powerfull and may be used for advanced
> purposes, but are simply not the same as translate.
>
> Use both.
>
>
> Just my two cents
>
> Cheers, Mathias
>
> > "why?" (which is good: that belongs on w3c-dist-auth), but I figured
> > people would want to at least hear a bit more reason why mod_dav is
> > taking a stance against it.
> >
> > Cheers,
> > -g
> >
>
> --
>                             virtual earth
>  Mathias Picker
>  Geschäftsführer      Gesellschaft für Wissens re/prä sentation mbH
>
>                             Mathias.Picker@virtual-earth.de
> 			    Fon +49 89  / 540 7425-1
>                             Fax +49 89  / 540 7425-9
>
> ----- End forwarded message -----
>
> --
> Greg Stein, http://www.lyra.org/
> _______________________________________________
> Interop mailing list
> Interop@webdav.org
> http://mailman.webdav.org/mailman/listinfo/interop
>
>

Received on Monday, 5 November 2001 16:45:15 UTC