Re: XML Blueberry Requirements

[Elliotte Rusty Harold <elharo@metalab.unc.edu>]

At 10:30 AM -0400 6/22/01, John Cowan wrote:
>Elliotte Rusty Harold wrote:
>
>
>>  Among other non-parser things that will be affected are:
>>  1. Test suites
>
>
>Some new tests will be needed.  Test suites can never be definitive:
>they always benefit from more tests.
>
>
>>  2. Other specs such as canonical XML
>
>
>How so?
>

Imagine an element whose name is written in Amharic. The canonical 
form of this element would need to use Amharic. However, canonical 
XML documents do not have an XML declaration. Thus if you rely on 
that to identify Blueberry documents, the canonical form of the 
document could not be properly identified. This problem could be 
fixed if you used a processing-instruction or an attribute to flag 
Blueberry documents. However, then XML 1.0 parsers wouldn't give up 
quickly enough.

This is just one problem I noticed in one spec. I suspect there are 
many similar, deep problems throughout the family of XML related 
specifications.

More generically, what to do about a spec such as XPath 1.0 which is 
complete and normatively references XML 1.0? and on which many other 
specs both complete and incomplete are dependent? Every one of these 
needs to be revised to support Blueberry.

>
>>  3. All sorts of books and printed documentation that will become 
>>inaccurate as a result of this change.
>
>
>Incomplete != inaccurate.  If we were making a silent change to XML,
>then they'd be inaccurate.

Speaking only for myself, there are statements in all my books which 
XML Blueberry would make untrue. Indeed, the very presence of the 
draft requirements means there are a few paragraphs I need to rewrite.

Note that I'm arguing against my financial interest here. The 
opportunity to rewrite a few pages and release XML Blueberry in a 
Nutshell or the XML 1.1 Bible would offer a huge return on my time.


>>  4. Systems that use a parser to read XML, but will need to be 
>>retested and validated when the parser they use is changed.
>
>
>No different from fixing a bug in the parser, or do you suppose that
>the last bug is already out?
>

Some systems are quite stable already. Some aren't. For myself, I've 
learned that bug fixes almost always introduce as many or more 
problems than they solve if I have what seems to be a stable system. 
I don't roll out new releases into my production systems no matter 
how many bugs they fix unless I am encountering one of those bugs 
already or have a clear and present need for one of the new features.

Once Blueberry documents escape into the wild (and they will, even 
for people who never see NEL or Amharic) existing systems won't 
handle them. You'll have forced people to upgrade their working 
systems. They may get to read documents written in Amharic, but 
doubtless countless other bugs will get introduced as well, and 
they'll spend days to years tracking them down and exterminating them.

>>  5. Systems that rely on regular expressions rather than a full 
>>parser. (I've seen a few of these out in the wild.)
>
>
>Granted.
>

-- 

+-----------------------+------------------------+-------------------+
| 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/     |
+----------------------------------+---------------------------------+