W3C home > Mailing lists > Public > xmlp-comments@w3.org > September 2004

Re: issue 503 is closed

From: A. Vine <andrea.vine@Sun.COM>
Date: Tue, 28 Sep 2004 19:04:54 -0700
To: Yves Lafon <ylafon@w3.org>, xmlp-comments@w3.org
Cc: I18n WSTF <public-i18n-ws@w3.org>
Message-id: <415A1846.2030209@sun.com>

Dear Yves and the XMLPWG,

The I18n WSTF have discussed your response, and have the following 
comments (inline):

Yves Lafon wrote:

> On Thu, 2 Sep 2004, A. Vine wrote:
> [issue 503 [1] covers the points 7 and 8 of your email [2]. ]
> The XMLP WG decided to close issue 503 by taking no action, with the 
> following rationale:
> point 7:
> The processing model does not mandate knowning the HTTP caching 
> mechanism, the use of the enclosed representation is application depend. 
> It may be used like a local HTTP cache, and the example in 4.3.3 [3] is 
> actually defining an extension to allow the application to use the 
> enclosed resource representation as a local cache.

We believe that at a very minimum to process human data, charset and 
language information must be known.  Since much of the inline data is 
likely human data, and in many of those cases will have a charset and a 
language, we believe that this needs to be specified.  At a minimum we 
would like to see a Content-Type header with a charset parameter and a 
Content-Language header (which is particularly important in light of the 
increasing use of Unicode encodings as the charset).

> point 8:
> It is up to the application to decide if the complete HTTP transaction 
> (in that case, indicating that it resulted in a 404) is required, and it 
> will then use an extension to carry that, or if the header will not be 
> added.

We feel that there is a danger when error conditions are not addressed, 
of non-internationalized de facto standards emerging.  This has happened 
  frequently in the past.  People need some mechanism for reporting 
errors, and if a standard does not specify one, they will make one up. 
We have seen this result in error messages in languages and charsets 
unknown to the recipient of the message.  There are other, non-i18n 
issues with not specifying error handling, but we are focusing on the 
i18n issues.

Some scenarios showing different types of errors and how they may be 
handled (e.g. no action, no response, machine code, human message, etc.) 
would be useful for the specification.  We agree that there are some 
scenarios that will not require a response, but we believe that others 
will.  A discussion of this in the document is recommended.

Andrea Vine
Sun Microsystems
For the I18n WSTF

> Please let the Working Group know if that resolution is acceptable or 
> not as soon as possible.
> Regards,
> [1] http://www.w3.org/2000/xp/Group/xmlp-cr-issues.html#x503
> [2] http://lists.w3.org/Archives/Public/xmlp-comments/2004Sep/0000.html
> [3] http://www.w3.org/TR/2004/CR-soap12-rep-20040826/#rep-http-headers

The trouble with the world is that the stupid are cocksure and the
intelligent are full of doubt. -Bertrand Russell, philosopher,
mathematician, author (1872-1970)
[...shouldn't that end with "or maybe not?"]
Received on Wednesday, 29 September 2004 02:08:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:17:00 UTC