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

[Shawn Villaron]

Right now we use the XSDs and the prose for code generation, automation and validation.  We currently do not use the RNG technology in those processes.  If it was made normative, I would feel pressure to retool internally ( something I am not even sure would be possible at this point, especially if I want to keep our existing work items funded and progressing [ which I do given the importance of delivering a Strict implementation ]).  

On Mar 23, 2011, at 8:55 PM, "MURATA Makoto" <eb2m-mrt at asahi-net.or.jp> wrote:

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