OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Closing Blueberry



At 3:59 PM -0700 7/18/01, Tim Bray wrote:
>xml-dev has no authority and is not part of any formal
>process, but if it were a W3C WG and I'd been the chair,
>at this point I would assert that I hear something like
>convergence going on.
>

FYI, I still haven't converged. I am not yet convinced that the benefits outweigh the costs. I am trying to seek more input from the communities that actually need this, but it may take awhile. I am also trying to figure out ways to reduce the cost, but so far there doesn't seem to be a willingness on the part of the Blueberry proponents to give up any ground in exchange for reducing the harm to the existing infrastructure.

I am particularly concerned that all my proposals for harm reduction in Blueberry are getting naysayed (particularly requiring that XML 1.0 legal infosets not carry an unnecessary Blueberry mark). Like all the other proposals in Blueberry there are costs and benefits associated with this proposal. It does introduce some real problems for streaming processes. However, these are only problems when somebody is choosing to generate a Blueberry document but does not know whether or not they will actually be generating Blueberry characters. I think this is a very small fraction of the potential uses.

I also proposed as a more limited version of this that did not have streaming issues; specifically that only documents actually labeled with a Blueberry character encoding such as UTF-8 or UTF-16 be allowed to carry a Blueberry mark. This was denied on the very weak grounds that additional encodings might be defined in the future. OK. They might be. But UTF-8, UTF-16, and a few others are still fully adequate to write Blueberrry documents. There is no need for character encodings beyond what we have now. If someone invents one in the future, that  won't change the fact that UTF-8, UTF-16, and a few others will still do the job. 

One thing is certain: simply stating that authors should not mark documents as Blueberry unless they actually need to is not sufficient and will not prevent needless propagation of incompatible Blueberry documents. Most authors will not even read the specification. They will rely on hearsay, gossip, and hype to decide what to do. Already, on this mailing list, we've seen repeated misconceptions about what Blueberry accomplishes. Despite everything that's been said, at least one subscriber to this list still thinks that Blueberry is necessary before XML markup can be written in Chinese. 

Do not look to third party documentation to dampen the coming conflagration. I can guarantee you that publishers will be racing to push out The XML Blueberry Bible, XML Blueberry for Dummies, Learning XML Blueberry in 21 Days, XML Blueberry Clearly Explained, and two dozen others. To justify the titles,  authors will be showing readers the Blueberry mark and telling them to use it. (This could perhaps be partially averted by naming Blueberry, XML 1.0.1. Most publishers are loathe to release books based on .0.x releases.) 

Magazines will be even worse. Reporters less well-informed than even the typical book author will be assigned to report on the new release and explain to their readers all the cool new features. Some book authors, some reporters, will get the story right; but just as many won't; and they will teach many developers that Blueberry is the wave of the future, and they should upgrade to it just as soon as they can. 

The only people who can be relied on to do the right thing here are the parser vendors. They're a small group of very well-informed developers who do read the spec. If the parsers make unnecessary Blueberryness an error users will learn to conform. This is the only plausible way to limit Blueberry to those documents that actually require it. 

-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+ 
|          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
|              http://www.ibiblio.org/xml/books/bible2/              |
|   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      | 
|  Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/     |
+----------------------------------+---------------------------------+