XML Schema Restriction for Complex types : Complete Redefinition?

Question

When adding restrictions to complexTypes in XML Schemas , is it necessary to rewrite all the elements used in the definition of the complexType? If so , Why can't it just reuse the existing element definitions and overwrite the new restricted ones?

For example , In the below ; When I just want to restrict the field country , Should I rewrite all the 3 fields again?

<xs:complexType name="customer">
  <xs:sequence>
    <xs:element name="firstname" type="xs:string"/>
    <xs:element name="lastname" type="xs:string"/>
    <xs:element name="country" type="xs:string"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="Norwegian_customer">
  <xs:complexContent>
    <xs:restriction base="customer">
      <xs:sequence>
        <xs:element name="firstname" type="xs:string"/>
        <xs:element name="lastname" type="xs:string"/>
        <xs:element name="country" type="xs:string" fixed="Norway"/>
      </xs:sequence>
    </xs:restriction>
  </xs:complexContent>
</xs:complexType>

So , It is pretty clear from the answer below as to why we have to rewrite the whole type.

Follow Up Question

What's the use of this restriction feature then?

One situation , I can think of ; is when you have to validate instance documents containing restricted types in place of base types in xml schema.

Say , If "B" is the base type and its restricted to "B*". Any instance document containing "B*" at the place where an element of type "B" is expected by the Schema Document would work.We would not have to write separate rules for each restricted type.(The attribute "xsi:type" in the instance document will validate it with the correct type.)Right?

Any Other uses of this feature?

Omitting the elements creates a constrained `complexType`. I think they didn't go with `including omitted elements unless specified not to`. — जलजनक, Feb 10 '13 at 13:58
`Should I rewrite all the 3 fields again?` Yes, you need to. — जलजनक, Feb 10 '13 at 17:22
might be able to avoid the repetition with `group` http://www.w3schools.com/xml/el_group.asp — Tim Abell, Oct 25 '16 at 13:35
But why for attributes there is a completly opposite logic?! — Nashev, Jun 21 '18 at 15:35

score 12 · Accepted Answer · edited Jun 20 '20 at 09:12

Your first question is "When adding restrictions to complexTypes in XML Schemas, is it necessary to rewrite all the elements used in the definition of the complexType?" No, only the ones you want to be part of the definition of the restricted type. But yes, all of the ones that should be part of the restriction. The content model in the restriction must stand on its own as a complete definition of the content model of the type. (It does not, on the other hand, have to specify all the attributes; they are inherited without change unless otherwise specified.)

Your second question is "Why can't it just reuse the existing element definitions and overwrite the new restricted ones?" It's a reasonable question. The answer is slightly tricky: Consider two arbitrary content models E and F. Now, we want to interpret F as a restriction of E that mentions only the elements and model groups in E that we want to change, and omits any mention of the elements and model groups we want alone. Is this a soluble problem, in the general case? Is it guaranteed to have a unique solution? It may seem obvious to you that the answer is yes in both cases, but it did not seem obvious to the designers of XSD at the time, and it does not seem obvious to me today.

For example, let E be

(a+, b+, c*){2}, (a+, b*, c+){3}

and let F be

a{3,4}

If we assume that everything in F is a restriction of something in E and everything else in E should be left alone, does F mean we want to restrict E to

(a{3,4}, b+, c*){2}, (a+, b*, c+)

or to

(a+, b+, c*){2}, (a{3,4}, b*, c+)

?

Addendum

@nikel asks for an XSD example. The example above is already an XSD example, though, so I suppose "an example in XSD syntax" is meant. I take the proposal to be that syntax like the following should work. First we have the base type, E:

<xs:complexType name="E">
  <xs:sequence>
    <xs:sequence minOccurs="2" maxOccurs="2">
      <xs:element ref="a" maxOccurs="unbounded"/>
      <xs:element ref="b" maxOccurs="unbounded"/>
      <xs:element ref="c" minOccurs="0" 
                          maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:sequence minOccurs="3" maxOccurs="3">
      <xs:element ref="a" maxOccurs="unbounded"/>
      <xs:element ref="b" minOccurs="0" 
                          maxOccurs="unbounded"/>
      <xs:element ref="c" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:sequence>
</xs:complexType>

Now let us imagine that we want type F to be able to restrict E without specifying a full content model. So we write

<xs:complexType name="F">
  <xs:complexContent>
    <xs:restriction base="tns:E">
      <xs:sequence>
        <xs:element ref="a" minOccurs="3" maxOccurs="4"/>          
      </xs:sequence>        
    </xs:restriction>
  </xs:complexContent>
</xs:complexType>

What should the effective content model of F be here?

Followup question

You ask, essentially, "in that case, what's the use of restriction?"

Reasonable question. The answer you suggest is a good one. More generally, sometimes we find it useful to know that every instance of type B* will be an instance of type B; derivation by restriction in XSD is intended to guarantee that invariant. Sometimes it seems helpful to define an abstract type with two or more concrete restrictions; that helps ensure that the various concrete realizations of the abstract base type are nicely related to each other, even if none is a subset or superset of any other.

There could be (no: there are plenty of) ways that derivation by restriction could be made clearer, simpler, and more convenient in XSD; not having to repeat the entire content model would be one of them. But then, that's true for pretty much everything in XSD. Its only real virtue is that it is supported by a lot of tools a lot of people seem to want to use.

Looks sensible for DTD's. Could you give a similar example for XSD's where this problem does not have a guranteed solution? — nikel, Feb 11 '13 at 10:28
I'm afraid I don't understand the question. Do you mean you would like to see this example in XSD syntax? Nothing in the example depends on the particular syntax used (nor is the syntax used the syntax of DTDs). — C. M. Sperberg-McQueen, Feb 11 '13 at 16:24
Yeah , I meant it in the XSD Syntax as you put it up.Sorry for my lack of knowledge of DTD , I thought it was in DTD. — nikel, Feb 12 '13 at 05:52
Got the reason now. Thanks for rephrasing your Excellent answer!. I added a follow up Question , Can you check that? — nikel, Feb 12 '13 at 06:09
Follow up question: If a type B declares a local element L, and a type D derives from B by restriction, *mustn't* element L also appear in D? Otherwise there would be values that are valid in D (i.e. ones with no L element) that aren't valid in B (i.e. ones which require an L element) -- this isn't restriction. My understanding is that inside D, you can place further restrictions on L than those already imposed by B. — CSJ, Oct 09 '14 at 03:28
@CSJ - your account works for the case where L is required in B, but if it's optional in B it need not appear in a restriction D. (Also, as a general rule, you should ask independent questions as new questions, and not bury them in comments on an existing question.) — C. M. Sperberg-McQueen, Oct 10 '14 at 00:31

XML Schema Restriction for Complex types : Complete Redefinition?

1 Answers1

Addendum

Followup question

Linked