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.

BTW, all implementations of server-driven negotiation that I am aware of 
already use individual URLs to identify the representations of a
negotiated URL.  Since Apache has two different internal mechanisms for
defining a mapping algorithm, not counting the API mechanisms, we'd
prefer to have the author select exactly what they want to do rather
than have to guess.  Unlike GET operations, bad things might happen if
we guess wrong.

....Roy

Received on Thursday, 24 July 1997 23:44:54 UTC