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

[MURATA Makoto]

Shawn,

What do you mean by a new technology?  When 29500 was cerated, Annexes
A and B were automatically created
from electronic schemas.  I think that we should restart this nice approach.

Regards,
Makoto

2011/3/24 Shawn Villaron <shawnv at microsoft.com>:
> We make extensive use of the XSDs ( from code generation to automation to validation ).  We then compliment that with the prose during our QA passes.
>
> The introduction of a new technology to represent definitions/constraints would create substantial overhead for us, likely slowing down our ability to evolve our support for Open XML ( e.g., supporting the Strict conformance class, incorporating the latest AMD and COR changes,, exploring new extensions being discussed by the technical committee, etc. ).
>
> Hope this helps.
>
> Shawn
>
> On Mar 23, 2011, at 8:22 PM, "MURATA Makoto" <eb2m-mrt at asahi-net.or.jp> wrote:
>
>> Rex,
>>
>> I think that all schema experts would like to get schemas from the subversion
>> repository and test the schemas there rather than reviewing schemas in the
>> DR Log.  Schemas (both XSD and RNG) in the DR log are too often incorrect
>> or incomplete.  Apart from you, who relies on schemas in the DR Log and
>> Annexes A and B?
>>
>> Only recently, schema maintenance in the Assembla repository started
>> to work.  For the first sets of AMs and CORs, the repository was not
>> available from the beginning.  Now, I believe that all schema changes
>> in the closed DRs (for the 2nd set of CORs) are in the repository.  In
>> my experience, maintaining schemas in the repository is an enjoyable
>> work.  Comparing schemas in the repository and those in Annexes A and B
>> is different.  I have done that three times (COR1, AM1, and upcoming REV).
>> I strongly think that this is the worst approach.
>>
>> 2011/3/24 Rex Jaeschke <rex at rexjaeschke.com>:
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>>
>> Praying for the victims of the Japan Tohoku earthquake
>>
>> Makoto
>>
>



-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto