RE: issue 503 is closed

No, I think we can get them to address our key points, provided our arguments are clear and sensible. I'm not second guessing you: I note that our responses have been rejected and am suggesting that follow-on responses be carefully thought through.

I understand and agree with their response about base64. I think our position there is unfounded and wrong. But it is important to deal with the encoding problem in C-T headers, etc.

As for textual data's language, that is sometimes important and sometimes not. Requiring the C-L header is not always useful.

My opposition to the term "human data" is that WS folks sometimes make the mistake of thinking that textual data intended for machines is never seen by humans. Text not explicitly for humans can still be affected by langauge and locale. I'm not quibbling your understanding of the problem, merely pointing out that in our responses to external working groups, we have to be careful to enumerate exactly what we mean.

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: A. Vine [mailto:andrea.vine@sun.com]
> Sent: 2004年10月14日 14:57
> To: aphillips@webmethods.com
> Cc: I18n WSTF
> Subject: 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 22:26:40 UTC