0

Named simpleType with string restriction and *pattern*. This sT basicType is applied to multiple elements. The catch is that two of these elements require type change to base="xs:ID".

This can be done by creating unique sT's: one sT for the fields that utilize the basic *pattern* restriction and another sT for the two fields requiring the ID base. Issue is that the pattern has to be duplicated in both sT declarations. It's a nit in my app but I wanted to learn if another approach was available. Specifically, one that would allow the pattern to be inherited and thus not duplicated for all the usual reasons. BTW: any alternative XSD 1.0 approach is OK. I'm not intending to restrict this to simpleType solutions only.

What I'd like to do is have a single pattern sT that can be applied to non-ID fields and have another derived sT that adds the ID base for the fields requiring ID while inheriting the pattern of the other sT. Thus, pattern is defined and maintained in one place only.

FWIW, this is a MSXML6 Excel app.

The following code snippet shows that the pattern is duplicated in each of the sT's.

Q) How to streamline this process?

<xs:simpleType name="basicType">
    <xs:restriction base="xs:string">
        <xs:pattern value="[A-Z]([A-Z0-9;&#45;]){1,8}">
            <!-- Upper case A~Z followed by 1~8, upper-case alphanumerics including hyphen. No whitespace. -->
        </xs:pattern>
    </xs:restriction>
</xs:simpleType>

<xs:simpleType name="IDType">
    <xs:restriction base="xs:ID">
        <xs:pattern value="[A-Z]([A-Z0-9;&#45;]){1,8}"/>
    </xs:restriction>
</xs:simpleType>
IronX
  • 345
  • 3
  • 9

1 Answers1

0

Note that xs:ID and xs:IDREF are legacy types that stem from DTD.

Your problem is a good case for XML Schema identity constraints. They are decoupled from the type hierarchy, and allow you to independently describe referential relationships between nodes.

In a schema, identity constraints are declared with xs:key elements, which mark the key nodes (=ID), and xs:keyref elements, which mark nodes that reference keys (=IDREF).

Take this simple document for example:

<root>
  <basic>BASIC</basic>
  <foo id="HELLO"/>
  <bar ref="HELLO"/> <!-- Must reference a <foo> -->
</root>

It can be described with the following schema. Note that basicType is only declared once and can be used for all nodes, whether they are simple elements, or key attributes:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

  <xs:simpleType name="basicType">
    <xs:restriction base="xs:string">
      <xs:pattern value="[A-Z]([A-Z0-9;&#45;]){1,8}"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:element name="root">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="basic" type="basicType"/>
        <xs:element name="foo">
          <xs:complexType>
            <xs:attribute name="id" type="basicType"/>
          </xs:complexType>
        </xs:element>
        <xs:element name="bar">
          <xs:complexType>
            <xs:attribute name="ref" type="basicType"/>
          </xs:complexType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>

    <!-- Identity constraints in the scope of <root> -->

    <xs:key name="basicKey">
      <xs:selector xpath="foo"/> <!-- Apply to <foo> children -->
      <xs:field xpath="@id"/>    <!-- Value of "id" attribute -->
    </xs:key>

    <xs:keyref name="basicKeyref" refer="basicKey">
      <xs:selector xpath="bar"/> <!-- Apply to <bar> children -->
      <xs:field xpath="@ref"/>   <!-- Match "ref" attribute with "id" from basicKey -->
    </xs:keyref>

  </xs:element>
</xs:schema>
Meyer
  • 1,662
  • 7
  • 21
  • 20
  • Hello @Meyer, the use of `key/keyref` is certainly a viable solution towards addressing this question. Taking it to the next level however, (i.e., unexpressed requirement), I find that I cannot populate a `list` element with members of `keyref`. Also, in this instance I am populating a `list` from members of two `ID` fields whose combined `IDREFS` collection can be used to populate the list. This I'd discovered with your help in another question [List element derivation](http://stackoverflow.com/questions/41478986/list-element-derivation) of mine. – IronX Jan 19 '17 at 15:34
  • 1
    Ah, I didn't make the connection with your previous question. Evidently, we are going somewhat in circles. I'm afraid that when limited to XML Schema, duplicate patterns probably are the least bad alternative. Though if the `list` is providing such a challenge, it might be worthwhile to investigate the possibility to store the list items in individual elements, i.e. `AB`. – Meyer Jan 19 '17 at 16:23