RE: Internationalization Requirements

>>I have stated that I believe that any authoring extension for a standard
>>which allows content language to be negotiated (hence hiding the URLs of
>>the individual language versions from the consumer) should provide the
>>same level of abstraction to the authors. It seems as though the rest of
>>the group does not agree.
>
>I can't speak for the rest of the group, but I can explain why that
>abstraction is neither possible nor desirable.
>
>Server-driven negotiation requires a namespace mapping between the
>server's back-end "files" (whatever storage name is used to store the
>representations) and the negotiated URL.  In order to write directly
>to a negotiated URL, the server would have to be able to identify which
>of these back-end "files" needs to be replaced, or where to store a
>new representation, AND how the negotiation algorithm for that URL
>needs to change to accommodate the new representation.  Likewise,
>the semantics of PUT must change to take this into account.  Since
>server-driven negotiation is not as simple as comparing a few header
>fields like Content-Language, the algorithm behind the namespace
>mapping can be very complex and server-dependent.  Standardizing
>a description of the mapping that uses the internal server storage
>names instead of individual URLs is impossible.  In any case, it makes
>both the protocol and the implementation far more complicated than
>it needs to be, since the author is far more likely than the client
>application developer to already know the nuances of the particular
>server on which the WebDAV operation is being performed.
>
>If a client attempts to write to a negotiated URL, then it should get
>an error or 300 redirection response that includes pointers (links) to
>the individual representation URLs.  This is exactly the same response
>that you would get by trying to write to a dynamically-generated resource
>instead of to the source of the resource.  The client can then ask the
>user to select the specific URL for the operation or enter a new one.
>Such a dialog is easier to standardize, easier to implement, and more
>likely to avoid mistaken results.
>

I don't accept the argument that this is complicated. If you can generate this list of URLs when a PUT is attempted then I don't know what is so complicated with redirecting a PUT to the correct language version of the URL if an appropriate header is present (especially if you need to know this in order to be able to provide this content for a GET anyway).

I don't think it is necessary to change the semantics of PUT, it would be good enough to have the ability to obtain a list of the language versions of a document i.e. give me list of the languages and the  mapping between each language and its source URL for a given negotiated (or source) URL. The client would then be able to construct the correct PUT command and no modifications to PUT would be necessary.

I am more prepared to accept the argument that an author is likely to know how her particular server maps a negotiated URL onto a particular source URL for a given language although this prevents the writing of an authoring client which allows for the authoring of multilingual resources in a user friendly way.

Cheers
Dylan

Received on Friday, 25 July 1997 05:07:26 UTC