Re: issue 503 is closed

Andrea, I would disagree with part of your message.

> We believe that at a very minimum to process human data, charset and
> language information must be known.

The charset is required, but for a tremendous amount of processing the
language is unnecessary, so that should be changed to something like the
following:

Charset information is required to process textual data. In addition,
language information is also required for certain types of processing.

> Content-Language header (which is particularly important in light of the
> increasing use of Unicode encodings as the charset).

Less important, but I don't see why you say the language header is any more
important with Unicode. After all, even with Latin-1, the charset doesn't
tell me the language.

‎Mark

----- Original Message ----- 
From: "A. Vine" <andrea.vine@Sun.COM>
To: "Yves Lafon" <ylafon@w3.org>; <xmlp-comments@w3.org>
Cc: "I18n WSTF" <public-i18n-ws@w3.org>
Sent: Tuesday, September 28, 2004 19:04
Subject: Re: issue 503 is closed


>
> 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 03:14:47 UTC