Re: Open Requirements Issues

On Wed, 18 Jun 1997, Jim Whitehead wrote:

> On June 6, Dylan Barrell wrote:
> 
> 1)  The server should support the notion of document language versions
> (similar in concept to renditions) and should always produce the language
> version corresponding to the language of the user's client, the explicit
> language version requested by the client (i.e. it should be possible to
> explicitly address a particular language version) or the default language.
> 2)  The client should be able to specify its preferred languages in order
> of preference and the server should present from the existing language
> versions the one highest on the client's list. Failing this the default
> language should be presented.
> 3)  It should be possible to specify to the server which language version
> is the default (master version)
> 4)  When asking for a list of objects in a collection it should be possible
> to obtain a list of all the different language versions of each resource
> (the default should simply return the list of default language resources)
> 5)  It should be possible to lock only a particular language version of a
> resource or all languages
> 6)  There must be a way of indicating which nodes in the version graph for
> each language can be considered equivalent (there might be a different
> number of versions for each language version)
> 
> 
> First, #1, #2, and #3 are already provided by HTTP/1.1 (although there is
> currently some debate on this issue).  Since we're building on top of
> HTTP/1.1, this can be considered base capability.

It's true that #1 and #2 are provided. #3 is not really provided.
On many servers, it's realized by a (Unix file system) link from
document.html to document.en.html, or vice versa. Other conventions exist.
I don't know if it's possible to tell the server to make a link using HTTP/1.1,
and the mechanisms differ from server to server, so it's not
satisfied in a way that would allow to build webdav clients offering
this functionality easily.


> #4 is interesting, perhaps Content-Language should be returned by INDEX, if
> it is defined for a resource.
> 
> As for #5, the view so far has been to assume that every variant of a
> resource is itself a resource, and hence has a URI.  If it has a URI, then
> it can be locked.   So this capability is provided for by the locking
> proposal.
> 
> #6 can be accomplished using links between resources.  Links are discussed
> in the properties draft.

These are some kind of "semantic links", not links in e.g. an Unix
file system?


> ---
> 
> To me, the areas within WebDAV which require i18n support are the value
> fields for properties and version comments, since these will be displayed
> to human operators of WebDAV clients.   As a result, I think that the
> following requirement could satisfy WebDAV i18n needs:
> 
> Internationalization:  All attribute values and version comments must have
> provisions for storing one or more of the encoding formats specified in
> ISO10646.
> 
> Another way might be to leave it more general, and have a statement like:
> 
> Internationalization:  All attribute values and version comments must have
> provisions for storing a representation in any human character set.
> 
> Although I'm not sure that ISO10646 and "any human character set" are
> identical.  I prefer referring to ISO10646 since it's more concrete, and
> avoid the issue of which character sets to support.

I think for a requirements document, it is enough to address the question
of the character repertoire, without reference to encoding issues.
So how about:

All attribute values and version comments must have provisions for
storing all characters from the Universal Character Set (ISO 10646).

As for actual implementation, using UTF-8 is probably the best solution.
Having several encoding formats complicates things a lot.


Regards,	Martin.

Received on Thursday, 19 June 1997 06:18:25 UTC