Key/IDREF checking as a pattern fragment

Hi there,

I have an element which, in its content, I wish to be able to construct a
function sequence which references other elements.  I am currently using the
following construct:

<xsd:element name="def">
 <xsd:complexType>
  <xsd:attribute name="id" type="xsd:ID"/>
 </xsd:complexType>
</xsd:element>

<xsd:element name="implement">
 <xsd:complexType>
  <xsd:choice minOccurs="0" maxOccurs="unbounded">
   <xsd:element name="doThis">
    <xsd:complexType>
     <xsd:attribute name="use" type="xsd:IDREF"/>
    </xsd:complexType>
   </xsd:element>
   <xsd:element name="doThat">
    <xsd:complexType>
     <xsd:attribute name="use" type="xsd:IDREF"/>
    </xsd:complexType>
   </xsd:element>
   <xsd:element name="doSomethingElseEntirely">
    <xsd:complexType>
     <xsd:attribute name="use" type="xsd:IDREF"/>
    </xsd:complexType>
   </xsd:element>
  </xsd:choice>
 </xsd:complexType>
</xsd:element>

Which allows me the following example content:

<def id="DEF1"/>
<def id="DEF2"/>
<def id="DEF3"/>
<implement>
 <doThis use="DEF1"/>
 <doThat use="DEF2"/>
 <doSomethingElseEntirely use="DEF3"/>
</implement>

However, for the sake of brevity in my instance XML, I would like to be able
to concatenate the do* elements and represent them as an attribute in the
<implement> element, something like the following:

<implement do="doThis(DEF1),doThat(DEF2),doSomethingElseEntirely(DEF3)"/>

I can write a xsd:restriction pattern for the attribute simple type as
follows:

<xsd:pattern
value="(doThis|doThat|doSomethingElseEntirely)\(\c+\)(,(doThis|doThat|doSome
thingElseEntirely)\(\c+\))*"/>

which (I hope) enforces the function names, the parens, and a requirement
that the content of the parens by characters permitted by xsd:NMTOKEN only,
but (and I bet you saw this coming) is there any way that I can enforce the
parens contents to be IDREFs?  At the moment I am contemplating either
leaving it with my clunky element sequence, or using the above pattern and
providing additional Schematron (or sim.) validation for the key validation.

Any suggestions would be gratefully received,

Stuart

Received on Friday, 29 November 2002 09:05:39 UTC