Re: [Serial] I18N WG last call comments

FWIW here's what we do:  we tout our products as being standards-based and 
therefore more interoperable.  When a customer complains about something that 
is, in fact, following the standard, but not doing what they want, we provide a 
custom solution (for $$$).  We also take a look at the standard to make sure 
that it makes sense, and if it doesn't, and we have the bandwidth, we try to 
improve the standard.

So the question is, will the majority be happy or unhappy with a particular 
decision on the standard?

I am not trying to answer that question, I'm only saying that customers 
complaining about the standard will always be there.  The issue is if lots of 
customers complain about the same thing, then it's a telling sign that the 
standard isn't serving the purpose.

Andrea
(from the cheap seats)

Michael Kay wrote:

> Thanks. There's no easy right answer on this one. It's similar to the
> question of whether products should accept "c:\a\b.xml" in places where a
> URI is required. Some products allow it. I've resisted, and report it as an
> error. When users find that it works on one product and doesn't work on
> mine, it's me they complain to. I tell them they are wrong and they should
> read the specs, but I can afford to do that because they aren't (at present)
> paying customers.
> 
> I would be happy with the stricter rule if we had imposed it from the start.
> I'm not happy with the idea that version 2 should be stricter than version
> 1. That's in good measure because, for the time being, people's first
> exposure to XSLT 2.0 is through my product, and when they get compatibility
> or usability problems, they report it to me as "a Saxon bug".
> 
> In addition, the XSLT spec has always been pragmatic about the reality of
> HTML interoperability. If the spec wasn't pragmatic in this way, then I
> think XSLT implementors would have to be pragmatic, and the weaknesses of
> HTML conformance would spill over into weaknesses in XSLT conformance. There
> are many ways that we allow XSLT stylesheets to generate non-conformant
> HTML, and I don't see that this one is particularly different from the
> others. Most areas where we have tried to be strict about what we generate
> (for example, in URI escaping) have led to practical problems for users.
> 
> Michael Kay
> 
> 
> 
>>-----Original Message-----
>>From: Martin Duerst [mailto:duerst@w3.org] 
>>Sent: 21 May 2004 08:09
>>To: Michael Kay; 'Henry Zongaro'; w3c-i18n-ig@w3.org
>>Cc: public-qt-comments@w3.org
>>Subject: RE: [Serial] I18N WG last call comments
>>
>>Hello Michael,
>>
>>The I18N WG (Core TF) has discussed your mail, and has asked
>>me to reply. I'm sorry for the delay.
>>
>>At 17:52 04/05/06 +0100, Michael Kay wrote:
>>
>>
>>>>>>I worry that we will get many complaints from users who
>>>>
>>>>are misusing
>>>>
>>>>>>these codepoints if we do this.
>>>>
>>>>How are they misusing these code points? The case we know is that
>>>>bytes in the rage 0x80-0x9F are used e.g. in iso-8859-1 but with
>>>>the intent of giving them the windows-1252 semantics.
>>>
>>>This was the case I had in mind. People create documents in 
>>
>>cp1252 and
>>
>>>declare them as iso-8859-1. And it all works, because the 
>>
>>errors cancel each
>>
>>>other out. If we oblige processors to detect this situation 
>>
>>we will be
>>
>>>asking users to pay for the extra processing cost, and in return the
>>>application that worked before will stop working. Will they thank us?
>>>Because if they won't, we shouldn't do it.
>>
>>Some users will be very thankful, others won't. The users that will
>>be thankful will be those that care about data integrity and 
>>interoperability
>>worldwide and in the long term. They will be able to fix a problem
>>in their data that they otherwise might not have found. As a result,
>>they will not only produce correct, valid output, but will also
>>make sure that their input data will work well in other circumstances,
>>such as searching, sorting, and any kind of other processing. Not the
>>least, with the introduction of XML 1.1, there are also such issues
>>as the confusion betwen NEL and the three-dot elipsis.
>>
>>There was a time when the mentality on the Web was 'everything goes',
>>which lead to the slippery slope of bugwards compatibility. We have
>>learned, with great pain, that this is a dead end, and we don't want
>>to go there anymore. XML is the clearest example of how this can be
>>done better. And I sincerely hope that XSLT will not be tempted to
>>go down the bugwards compatibility slope.
>>
>>The C1 area is forbidden in HTML exactly because it is a very easy
>>and cheap way to help people check and (if necessary) clean up their
>>data. RFC 2070 (http://www.ietf.org/rfc/rfc2070.txt) was written
>>almost 10 years ago. That C1 is allowed in XML is, according to
>>James Clark, an oversight. XML 1.1 has corrected it.
>>
>>
>>
>>>>In some way just a detail, but: There is currently no XSLT 2.0
>>>>code that will stop working. XSTL 1.0 doesn't have the XHTML
>>>>output method.
>>>
>>>I may have lost the thread, but I thought we were discussing 
>>
>>the HTML output
>>
>>>method?
>>
>>Okay, sorry. There is still no XSLT 2.0 code that will stop working,
>>even for the HTML output method. And because the XHTML output
>>method is supposed to work according to the compatibility guidelines,
>>it of course also should forbid producing C1 character output.
>>
>>Regards,    Martin.
>>
>>
>>
>>>>>[20] 6.4 HTML Output Method: Writing Character Data: "Certain
>>>>
>>>>characters,
>>>
>>>Michael Kay
>>
>>
> 

-- 
I have always wished that my computer would be as easy to use as my telephone. 
My wish has come true. I no longer know how to use my telephone.
-Bjarne Stroustrup, designer of C++ programming language (1950- )

Received on Friday, 21 May 2004 13:38:39 UTC