Usage of `<dataRef>`+`<dataSpec>` and `<macroRef>`+`<macroSpec>`

[martindholmes]

The ATOP team notes that:

• A <dataSpec> can be pointed to using a <dataRef> in the context of an attribute definition; but
• <dataSpec> allows the use of <elementRef> or <anyElement>, which would result in an element being included in the content model of an attribute, which is of course invalid.

We suggest that it would be useful to:

• Clarify in the prose that <dataRef> and <dataSpec> should be used for the definition of attributes, while <macroRef> and <macroSpec> should be used for the definition of content models for elements.
• Schematron should be added to prevent the use of <anyElement> or <elementRef> as a descendant of <content> in the context of a <dataSpec>.

This would not catch all potential errors, of course, because ODD-chaining could still result in elements ending up in the content model of attributes, but the ODD processor can catch these. But the most straightforward cases would be caught by Schematron.

[ebeshero]

From Council discussion: Consider whether we should prevent macroRef from being used in <attDef>? That would prevent the other way of putting an element inside an attribute.

[joeytakeda]

Thinking about this the other way: what should a dataSpec allow as a child of content? Right now, it allows:

• alternate
• anyElement 
• classRef 
• dataRef 
• elementRef 
• empty 
• macroRef 
• sequence 
• textNode

I would suggest that nothing other than <dataRef> makes sense; the only reason I can see a dataRef being used in an element would be to specify a <valList> for an element's content (which is handled via dataSpec/valList anyway).

[sydb]

@ebeshero — At first blush keeping <macroRef> out of <attDef> seems like a good idea. But I do not think it is allowed, anyway.

@joeytakeda — Good thought experiment. But I claim <alternate>, <sequence>, <textNode>, and even <empty> are useful. Imagine, e.g., that I want a datatype that gives me latitude & longitude with leading zeroes in degrees to 2 decimal places and elevation in meters:

        <dataSpec ident="lle">
          <content>
            <sequence>
              <dataRef name="float" restriction="-?[0-9][0-9][0-9]\.[0-9][0-9]"/>
              <dataRef name="float" restriction="-?[0-9][0-9][0-9]\.[0-9][0-9]"/>
              <dataRef key="teidata.count"/>
            </sequence>
          </content>
        </dataSpec>

Here in the USA when using the NEMSIS scheme for encoding electronic medical records the field for a drug to which the patient is allergic may be expressed as an ICD10 code or by using the RxNorm name of the medication. Perfect case for <altnernate>. (And there are a dozen actual use cases of //dataSpec/content/alternate in p5.xml.) And certainly <textNode> is needed to express “you can put anything in here (as long as it is escaped per the rules of XML).” Would be useful for @alt if you were writing an ODD to describe XHTML, no? (And it is used twice in P5.) It is a bit harder (for me) to formulate an argument for <empty>. After all, maxOccurs="0" would have the same effect, wouldn’t it? (Why we allow maxOccurs=0 is another question.) My thought is that it is useful for those who use programs to write schemas to be able to make the <content> valid by putting in <empty>, whether that <content> is in an <elementSpec> or something else. I do not actually know this is the case, I just think so.

It is obvious (at least, to me) that <classRef> inside a <dataSpec> is about as bad an idea as <elementRef> (or <anyElement>, which I think of as a special case of <elementRef>).

That leaves <macroRef>. It is useful for expressing a constraint in RELAX NG. But, of course, you could just put the RELAX NG directly inside the <content> of the <dataSpec>, so why would you need <macroRef>? The only reason I can think of off the top of my head is that maybe you want to use the same snippet of RELAX NG in several places. Thus being able to refer to it eliminates duplication of code.

So it seems to me of the 9 possible children of <content> I would allow 6 (<alternate>, <dataRef>, <empty>, <macroRef>, <sequence>, and <textNode>) inside <dataSpec> and disallow the other 3 (<anyElement>, <classRef>, and <elementRef>).

[sydb]

P.S. Worth mentioning this is a perfect use case for a co-occurrence constraint or contextually-variant content model (see #1744).

[ebeshero]

Resolved with PR merge.