Re: issue 503 is closed

Addison, Mark, et al,

{caps because I'm too lazy to do underscores everywhere}

Well, much as I would LOVE to have the luxury of getting everyone's 
opinions together BEFORE I construct a note, in this case, I didn't have 
the time/relevant folks were not at the meetings to discuss.  And 2 of 
you are somewhat opposed in your opinions, so you 2 would have to come 
to some agreement.

Personally, I don't care.  The term "human data" is as opposed to 
computer data.  For MOST protocol data (but not ALL) the charset 
handling is defined and no additional header info is necessary.

The language is necessary only some of the time, but the minute you say 
that to non-i18n people, suddenly any case they work on is one of those 
cases where it's not important.  So to make it easy for others to grok, 
I threw it in there (it was originated by someone else at the meeting).

In any case, it looks like no matter what we say they just don't want to 
put any i18n into their spec, so this is all moot.

Andrea

Addison Phillips [wM] wrote:

> FWIW, I agree with Mark's note. I also have some concerns about our response...
> 
> 
>>We believe that at a very minimum to process human data, charset and 
>>language information must be known.  
> 
> 
> I think the stress on human data is misplaced. There is a lot of text in the world that is not human data but which is text (many XML files, for example, or, in my world, EDI files of all kinds) in which the character encoding is vital to interpreting the data.
> 
> 
>>  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).
> 
> 
> I don't agree with the need for a Content-Language header *requirement*, but the C-T header I do agree is necessary.
> 
> Best Regards,
> 
> Addison
> 
> Addison P. Phillips
> Director, Globalization Architecture
> webMethods | Delivering Global Business Visibility
> http://www.webMethods.com
> Chair, W3C Internationalization (I18N) Working Group
> Chair, W3C-I18N-WG, Web Services Task Force
> http://www.w3.org/International
> 
> Internationalization is an architecture. 
> It is not a feature.
> 
> 
>>-----Original Message-----
>>From: public-i18n-ws-request@w3.org 
>>[mailto:public-i18n-ws-request@w3.org]On Behalf Of A. Vine
>>Sent: 2004年9月28日 19:05
>>To: Yves Lafon; xmlp-comments@w3.org
>>Cc: I18n WSTF
>>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?"]
> 
> 
> 

-- 
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 Thursday, 14 October 2004 23:03:42 UTC