xsd - In XML Schema, why does an element group tag even exist? -

xsd - In XML Schema, why does an element group tag even exist? -

from understanding, group used create named sequences (choice, sequence, all) can later referenced.

however, why necessary when complextype can used accomplish same thing , is, in addition, much more powerful? isn't un-dry? not mention group tag acts both definition of type, , @ same time, can reference type, depending on whether utilize ref or name attribute. isn't terribly confusing , unnecessary? or missing important?

named element , attribute groups (xs:group , xs:attributegroup) important.

in effect, allow define sort of surrogate complextypes, without limitations of real complextypes.

limitations of xs:complextype

suppose define base of operations complextype this:

<xs:complextype name="base"> (base element model) </xs:complextype>

then, want reuse (base element model) across xml schema, can deriving other complextypes this:

<xs:complextype name="derived"> <xs:complexcontent> <xs:extension base="base"> (extension element model) </xs:extension> </xs:complexcontent> </xs:complextype>

but when complextype extended, new elements added base of operations elements sequence. new content model looks follows:

(base element model), (extension element model)

and cannot have different (e.g. place extension elements in front end of base of operations elements). that's how type extension in xsd works!

and here, can stop on , xsd language designed. still, question remains. why designed so? why derivation of complextypes in xsd not made more convenient? reason this: the derived type must comply base of operations type. cannot have extension of base!

suppose have software knows how process elements of type a. software may assume type a might extended, in case, must able find in element supposed of type a knows/expect type a... , element content inherent type a must come first!

so, using complextype derivations cannot produce derived type content model looking this:

(extension element model), (base element model)

that is, place extension elements in front end of base of operations elements.

again, may wonder why? perhaps, software made more sophisticated able sort out this?

perhaps. against 1 of fundamental principles laid in xsd language: element content model must deterministic. means sequence of elements must possible recognize particular content model (defined in xml schema) using single pass. if software knows type a, must first somehow pass elements of (extension element model) in order find knows how deal with. cannot deterministic, of course!

how xs:group saves day

when define group, not supposed behave stand-alone complextype (able assigned elements type). piece of content model can reused elsewhere.

you want set extension elements in front end of base of operations elements? no problem! define base group:

<xs:group name="base"> (my base of operations element model) </xs:group>

then, can derive derived complextype this:

<xs:complextype name="derived"> <xs:sequence> (my extension element model) <xs:group ref="base"/> </xs:sequence> </xs:complextype>

xml xsd