Re: Pattern constraint on string content of complexType having attribute and choice

Hi Wyatt,

> Our current problem -- with which I need help
> urgently -- is basically this:
> (a) we require a Schema Element type that accepts
> tag Attributes and a Choice of child Elements; *plus*
> (b) a RegEx Pattern constraint on string character
> data that can appear between the tags of this Element
> type.

You can't do this. In XML Schema, elements either have simple content
(text which conforms to a simple type) or complex content (element
children, perhaps with untyped text intermingled).

> Q1: Can we 'promote' a simpleType to a complexType
> in some way, eg, the following?
>
> <xs:simpleType name="base_Type-ST" abstract="true">
>   <xs:restriction base="xs:string">
>     <xs:pattern value="[...myRegEx...]"/>
>   </xs:restriction>
> </xs:simpleType>
>
> <xs:complexType name="base_Type-CT" abstract="true">
>   <xs:simpleContent>
>     <xs:extension base="base_Type-ST"/>
>   </xs:simpleContent>
> </xs:complexType>

This is fine. You can do it one step, of course:

<xs:complexType name="base_type-CT" abstract="true">
  <xs:simpleContent>
    <xs:restriction base="xs:string">
      <xs:pattern value="[...myRegEx...]" />
    </xs:restriction>
  </xs:simpleContent>
</xs:complexType>

> And, then use the 'promoted' type in our target
> complexType declaration by extension, eg, the
> following?

No, you can't. See the Schema Component Constraint: Derivation Valid
(Extension) Clause 1.4, which reads:

  1.4 One of the following must be true:
  1.4.1 The {content type} of the {base type definition} and the
        {content type} of the complex type definition itself must be
        the same simple type definition.
  1.4.2 All of the following must be true:
  1.4.2.1 The {content type} of the complex type definition itself
          must specify a particle.
  1.4.2.2 One of the following must be true:
  1.4.2.2.1 The {content type} of the {base type definition} must be
            empty.
  1.4.2.2.2 All of the following must be true:
  1.4.2.2.2.1 Both {content type}s must be mixed or both must be
              element-only.
  1.4.2.2.2.2 The particle of the complex type definition must be a
              ·valid extension· of the {base type definition}'s
              particle, as defined in Particle Valid (Extension) (§3.9.6).

In what you're trying to do, the {content type} of the base type
definition is the simple type base_type-ST and the {content type} of
the complex type definition itself is the pair "mixed" and the
particle corresponding to the <choice>. Clause 1.4.1 doesn't apply
because the complex type definition itself doesn't have a simple type
as its content type. Clause 1.4.2.2.1 doesn't apply, and neither does
1.4.2.2.2 because 1.4.2.2.2.1 isn't met, so Clause 1.4 as a whole
isn't met.

> Q2: Alternatively, is there a way to constrain the
> string character-data content of a complexType by
> restricting its type in another complexType
> declaration, eg, something like the following?

No. Schema Representation Constraint: Complex Type Definition
Representation OK says that if you have a <xs:simpleContent> element
then the base attribute must point to a complex type with simple
content (or a simple type).

Interestingly, this is one of the things that is also not supported by
RELAX NG. You should probably leave the constraints on the formatting
of the text loose within the schema and then check them in external
code. (I'd say "Schematron" but you need something that supports
regular expressions; Schematron is usually limited to XPath 1.0,
though there's no real reason why you couldn't use XPath 2.0 with it.)

Just because I'm interested, can you give more details about the
markup-language design that you're trying to support here?

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/

Received on Wednesday, 11 August 2004 14:17:59 UTC