On Mon, 2007-11-12 at 15:40 -0500, noah_mendelsohn@u... wrote:
 
> So, whatever its other pros and cons, it's pretty simple at the XSD 
> component level to express that element E has a type T that allows just a 
> sequence (A,B,C). 

How do you express anything at the component level? 

To get to the component level, you have to go past elementFormDefault,
ComplexType, ComplexContent, and so on. Even at the component level you
still need to understand types, and other additional concepts. And you
have to understand grammars. 

When you understand grammars, you will guess that (A,B,C) means 
 The first child is A  
 The second child is B
 The third child is C 
 There are no other elements

So if asked to explain the content model, you would get something
completely akin to the equivalent Schematron assertions. 

<sch:rule context="el">
 <sch:assert test="*[1]/name()='A'">The first child is A</sch:assert>  
 <sch:assert test="*[2]/name()='B'">The second child is B</sch:assert>
 <sch:assert test="*[3]/name()='C'">The third child is C </sch:assert>
 <sch:assert test="count(*)= count(A) + count(B) + count(C)">
	There are no other elements than A, B, or C</sch:assert>
</sch:rule>

(If you asked an analyst which was simpler to understand, the assertions
in bullet list form, or the XSD pretty printed, I bet the assertions
would win.)

However, what if the language designer had meant
 There is always an A
 B always follows the A
 C is always the last element after any A
 There are no other elements yet

The same content model would apply, but the content model gives no
indication of the relationships that force a particular order: to an
extent the grammar is a hack that approximates what is going on in the
developer's head.

More importantly, grammars don't say anything about why; there is no
traceability back to business requirements. Consequently orders are
enforced for the sake of fitting in with the grammar and maintainability
where the business requirement may only require certain partial orders. 

For example, what about a content model that says "The first element
must be a title, the second element is an optional metadata element,
then there are 100 elements in any order, and the last element is
footnote."  Now in XSD you have to add an artificial container for the
100 elements, but there is no structural or modeling benefit for it: it
is just extra cruft, another thing to type and remember, another place
for a typo in an XPath, another thing to explain to the customer who
says "but are generating our data from a system that cannot handle
structure, it must only be one level deep" (This is not a strange
requirement: this is a constraint of a system I am working with the last
few weeks.)

A good assertion says "An X should have a Y because Z" where Z is
traceable back to a business requirement. Whenever there is "An X should
have a Y because that is a limitation of our system" then you have a
potential either for limited functionality compared to the requirements
or for extra work compared to the requirements. 

Cheers
Rick Jelliffe