Re: Open Requirements Issues

OK, I'm going to take a stab at the i18n requirement again.

On June 5, Terry Allen wrote:
>How about "nothing in this specification shall be interpreted to
>inhibit internationalization".  As for the character set, the IAB
>view is ISO 10646.

Well, the only problem with this is that it's a negative requirement, and
it is hard to determine when it has been satisfied.

On the other hand...

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.

#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.

---

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.

- Jim

Received on Wednesday, 18 June 1997 19:59:58 UTC