[
Lists Home |
Date Index |
Thread Index
]
> -----Original Message-----
> From: Tim Bray [mailto:tbray@textuality.com]
> Sent: Friday, December 14, 2001 8:03 PM
> To: xml-dev@lists.xml.org
> Subject: [xml-dev] Some comments on the 1.1 draft
>
>
> 5. I strongly feel that #x85 (NEXT LINE) should not be added to
> the S production. The reason is a simple cost-benefit analysis;
> the proportion of computing installations where this is an issue
> is not large and is shrinking as a proportion of the
> infrastructure. Supporting this change imposes significant
> conversion costs on the rest of the world; the total global
> net cost would be significantly less if the mainframe software
> infrastructure took the necessary corrective measures to deal
> with XML 1.0 as specified.
I'm out of my depth here, but this argument doesn't smell right to me. I
thought we concluded in the massive Blueberry thread a few months back that
#x85 probably should have been included in the S production in the first
place, and wasn't mainly because of a lack of mainframe expertise among the
members of the original WG. (PLEASE set me straight if there was a better
reason, I don't claim to know much about mainframes myself except that they
generate a good bit of the revenue that pays my salary <grin>).
It would seem to me that XML 1.1 is about doing the right thing early in
XML's life so that it can be a more stable foundation for the future. I
agree that some characters such as 0 and #x1-#x1F will cause such nasty
problems for almost any ASCII-based system that XML should bow to simple
pragmatism and leave them out. BUT there is an IMMENSE amount of data in
mainframe databases that will probably be exposed via XML one day. It's not
IBM that will pay the cost of debugging all the programs that neglect to
translate #x85 into a politically correct separator when exposing these
legacy systems as web services. And it is potentially OUR bank accounts and
insurance policies in these legacy systems that are vulnerable to someone
getting this wrong.
Microsoft gets its way rather often in the W3C simply because arguments that
their customers will be inconvenienced by some proposal strikes close to
home ... we are ALL their customers, and we know damn well who pays when
their customers are inconvenienced. We are all the customers of IBM's
customers, and we will pay, directly or indirectly, if the "mainframe
software infrastructure [is forced to take] the necessary corrective
measures to deal with XML 1.0 as specified."
Once again, I don't claim any real knowledge here, but something doesn't
smell right ... the people who know the most about this have flagged #x85 as
a significant problem; the W3C is going to introduce a batch of incompatible
changes to the XML character processing productions anyway, so why not defer
to their expertise?
|
