问题
From my understanding, group is used to create named sequences (choice, sequence, all) that can later be referenced.
However, why is this even necessary when complexType can be used to accomplish the same thing and is, in addition, much more powerful? Isn't this very un-DRY? Not to mention that the group tag essentially acts as both a definition of a type, and at the same time, can be a reference to that type, depending on whether you use ref or name attribute. Isn't this terribly confusing and unnecessary? Or am I missing something important?
回答1:
Named element and attribute groups (xs:group and xs:attributeGroup) are very important.
In effect, they allow you to define a sort of surrogate complexTypes, however without the limitations of real complexTypes.
Limitations of xs:complexType
Suppose you define your base complexType like this:
<xs:complexType name="Base">
(base element model)
</xs:complexType>
Then, you want to reuse that (base element model) across your XML schema,
which you can do only by deriving other complexTypes like this:
<xs:complexType name="Derived">
<xs:complexContent>
<xs:extension base="Base">
(extension element model)
</xs:extension>
</xs:complexContent>
</xs:complexType>
But when a complexType is extended, the new elements are added to the base elements as sequence. The new content model will looks as follows:
(base element model), (extension element model)
and you cannot have anything different (e.g. to place extension elements in front of base elements). That's how the type extension in XSD works!
And here, I just can stop on this and say that so XSD language was designed. But still, the question remains. Why was it designed so? Why the derivation of complexTypes in XSD could not be made more convenient? The reason is this: The derived type must comply with the base type. You cannot have anything as an extension of anything as a base!
Suppose you have a software that knows how to process elements of type A.
The software may assume that actually the type A might be extended, but in any case,
it must be able to find in an element supposed to be of type A everything it knows/expect from type A...
and the element content inherent to type A must come the first!
So, using complexType derivations you cannot produce a Derived type with a content model looking like this:
(extension element model), (base element model)
that is, to place the extension elements in front of the base elements.
Again, you may wonder why? Perhaps, the software could be made more sophisticated to be able to sort out even this?
Perhaps. But that would be against one of the fundamental principles laid in XSD language: any element content model must be deterministic.
That means that for any sequence of elements it must be always possible to recognize a particular content model (defined in an XML schema) using a single pass.
If the software knows only about the type A, it must first somehow to pass the elements of that (extension element model) in order to find what it knows how to deal with. That cannot be deterministic, of course!
How xs:group saves the day
When you define a group, it is not supposed to behave like a stand-alone complexType (able to be assigned to elements as their type). It is just a piece of content model that can be reused elsewhere.
You want to put the extension elements in front of the base elements? No problem!
Just define the Base as a group:
<xs:group name="Base">
(my base element model)
</xs:group>
Then, you can derive your Derived complexType like this:
<xs:complexType name="Derived">
<xs:sequence>
(my extension element model)
<xs:group ref="Base"/>
</xs:sequence>
</xs:complexType>
回答2:
When you ask a "why" question, there are two possible approaches to answering it: (a) what was in the mind of the committee when they specified this feature, and (b) why would I want to use this feature? Answering (a) can be very hard even if you were a member of the committee; answering (b) is usually easier. Sometimes the answer is, don't try to use this feature, ever: there are certainly some things in XSD like that, but named model groups are not one of them.
Essentially it's a re-use and modularity mechanism. If you have 17 different elements, and each of them is allowed to end with any or more of the elements Note, Author, and/or DateCreated, then putting these three into a group and referencing the group makes it easier when you add an 18th element with the same pattern, or when you want to add DateModified as an additional option. Also a model group can be the target of xs:redefines - though I would avoid using redefines if at all possible.
The design of using one element name (xs:group) with different meanings depending on whether there is a @name or @ref attribute is something you either like or dislike. (Why did they paint the front door red? Answer, they liked it that way.) XML has no rigid design rules, different people will make different design choices, and it's not a big deal. There are worse things than this to complain about in the design of XSD's concrete syntax.
来源：https://stackoverflow.com/questions/26268938/in-xml-schema-why-does-an-element-group-tag-even-exist