Maintaining schemas and tracking changes (formerly, Making RELAX NG schemas normative rather than non-normative)

Rex Jaeschke rex at RexJaeschke.com
Thu Mar 24 03:37:11 CET 2011


In response to my initial posting, several members suggested that it is
quite easy to maintain schemas electronically, and then to drop them into an
annex of a Part just before going to publication. This involves the more
general area of tracking changes to schemas, and as that isn't at all
related to whether or not RELAX NG schemas should be normative, I've split
the discussion off under this new subject.

The proposed solution is obvious; however, it addresses about 2% of the real
problem. And it doesn't even handle that 2% completely. (Specifically, the
schema annexes currently contain hundreds of hyperlinks from type references
to those types' definitions. Of course, these links do not exist in the
electronic schemas. But as the 4 Parts are no longer machine generated, I do
not plan to maintain such linkage for new/changed types going forward.)  

Now to the other 98% of the problem, which the proposal does not address.
Only once in the life of a Part of an edition of 29500 is a complete schema
actually represented in a "printed" annex, and that is when the Part is
about to be submitted for publication of a new edition (resulting from a
consolidated reprint or revision). 

Up until now, all changes to 29500 have been documented in the DR log, and
that log was then used to generate the COR 1 set and then the AMD1 set. As
we were resolving DRs, I argued that we shouldn't declare a DR to be closed
until all the detailed changes were documented as part of the corresponding
DR(s) entries in the log. And I was successful except for RELAX NG edits,
which came sometime (very much) later. (I accepted that delay because
support for this schema was not required; that is, it was non-normative).
Anyone could look at a closed DR at any time and see exactly what XSD schema
changes had been agreed to by WG4. And given that the complete history of a
DR's processing is captured there, interim schema changes are also recorded.
And as they were maintained using pseudo-change-tracking notation, the
reader could see what was deleted or added. CORs (and AMDs like AMD1) need
to continue to show JUST the changes being made, NOT the whole schemas.

I believe that if we stop showing the schema changes in the DR log, that
would be a major step backwards in allowing readers to see all the
information in one place. It would also make the generation of a COR or AMD
much more complicated requiring a lot of work to be done very late in the
process rather than as each DR is closed. Now, maintaining schemas changes
in the DR log as well as electronically could lead to differences between
them. How can that happen? If WG4 approves the changes documented in the DR
log then those are the official ones (even if they are technically incorrect
or don't validate!). If the electronic schema is found to be different then
someone made changes there without having WG4 review them and approve them
formally in a teleconference or F2F meeting, or I made an error in what was
recorded in the meeting minutes and/or DR log. To make sure differences
don't happen, all schema changes should be tested electronically BEFORE the
DR is accepted as closed. Any change to the printed or electronic version
after that requires the DR to be re-opened.

Rex












More information about the sc34wg4 mailing list