Making RELAX NG schemas normative rather than non-normative

[rjelliffe]

 On Thu, 17 Mar 2011 10:33:01 +0100, Jirka Kosek <jirka at kosek.cz> wrote:
  > 3. normative W3C XML schema, normative RELAX NG schema
>    - compromise which can make everybody happy


 How can they both be normative when they may contradict at the edges?

 Not contradict in the sense of not allowing any documents that are 
 valid under both, but contradict in the sense that some documents 
 allowed by one will not be allowed by the other. Implementers will 
 presumably choose one or the other, but not test with both.

 (And if a common subset of features is used, so that they express 
 identical markup languages, why is there any need to have both as 
 normative, when it would be just an different syntax?)

 --I guess one answer is that the schemas are both models that 
 approximate the document type, which was Goldfarb's comment on the 
 distinction between the document type declarations (schemas) and the 
 document type definition (schemas plus constraints).--

 How much of this problem is just that whichever is normative needs to 
 be augmented with enough information to generate satisfactory schemas in 
 the alternative schema language? And that where there is a significant 
 difference, it is something the standard's reader should be informed of.

 I have not kept up with details of the current production system, but 
 have we/could we moved over to an interleaved system for maintenance?:

 <xsd:element name="XXX">
    <xsd:appinfo>
       <xsd:annotation>
          <iso-maintenance:relax-equivalent>
            pattern fred = element XXXX { ZZZ }
          </iso-maintenance:relax-equivalent>
        </xsd:annotation>
    <xsd:appinfo>
    <xsd:complexContent type="ZZZ" />
 </xsd:element>

 (Details probably wrong above, and not clear.) But the idea is that 
 where there are different things expressed that cannot be autogenerated, 
 the XSD can instead have the appropriate RELAX NG hard coded inside.



 Cheers
 Rick Jelliffe