[
Lists Home |
Date Index |
Thread Index
]
>Normally, of course, committees try to use the easiest method
>and will say "of course, what we *meant* to say was ...".
>
>In the W3C world there is nothing in between an erratum
>and a version up, so errata can be expected to also contain
>corrections relating to exigencies.
>
>This is a procedural issue: you buy into an organization's technology,
>and you may also have to live with their procedures too.
>
The W3C Process document states:
W3C may publish a revised version of a Recommendation to make minor
clarifications, error corrections, or editorial repairs, without
following the Recommendation track. The status section of an
editorial revision must indicate its relationship to previous
versions (e.g., that it supersedes previous versions). The Team must
notify the Members when an editorial revision of a Recommendation is
published.
If more substantial revisions to a Recommendation are necessary, a
Working Group must follow the Recommendation process to produce the
revision. The status section of any Recommendation must indicate its
relationship to previous related Recommendations (e.g., an indication
that a Recommendation supersedes, obsoletes, or subsumes another,
etc.).
This is a bit wishy-washy about what an "error correction" is. I tend
to think, though, that there's no error in the version in the BNF
grammar in XML 1.0 or the namespace URI for the xmlns prefix. In
these cases, the original working group possibly didn't make the best
decision, but it wasn't in error. They made a clear and consistent
choice. They knew what they were doing. They decided that reporting
version strings other than 1.0 as an error was optional, and that's
what they wrote in the spec. They didn't have a slip of the keyboard.
Ditto for the namespace URI of the xmlns prefix.
The problem is that the W3C is not following its own advertised
process. They are making substantial revisions to recommendations
without following the Recommendation process. In so doing it's no
surprise that they are imposing major costs on implementers, users,
documenters, and other spec clients without even giving them an
opportunity to comment before hand. The namespace issues were in
direct conflict with the established behavior of SAX 2. The version
issue will cause problems for some parsers, all test suites, and
possibly some end user programs.
There are other problems. E2 adds a validity constraint, though
arguably this was always implied by SGML. E41 adds an additional
legal value for xml:lang attribute, though most parsers won't have
checked this. Here, however, it's entirely possible that client apps
were relying on the old legal values. E36 allows more documents to be
standalone="no" than could be previously. E10 is huge. It adds a new
one of those annoying error conditions that parsers may or may not
report in the event that an unknown entity is found in an attribute
value by a non-validating parser. (Why skipped entities in attribute
values should be treated differently than skipped entities in PCDATA,
I'm not sure but there's probably a reason.)
All of this is happening without notice or feedback. We don't know
how serious the breakage is because mostly this gets slipstreamed in
before anyone notices.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| XML in a Nutshell, 2nd Edition (O'Reilly, 2002) |
| http://www.cafeconleche.org/books/xian2/ |
| http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.cafeconleche.org/ |
+----------------------------------+---------------------------------+
|
