- 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>
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. Regards, 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