Re: [xml-dev] Is Schematron (using XPath 2.0) functionally a superset of

["Fraser Goffin" <goffinf@googlemail.com>]

> (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.)
 

maybe, although this rather depends on the analyst, and, that represents another whole class of factors which may drive a decision when choosing technology. That is, what skills do I have available, are those skills also present in my key trading partners if we're going to exchange artefacts, what tooling support is available, and so on .... Add a bunch of namespaces into the XML instance and XPath's can get a bit hairy too. I'm not saying XSD is easier to understand than XPath, nor that XPath is easier than XSD, it depends on the problem, the people and the tools. As Noah was saying, sometimes the 'rule of least power' (or at least 'common' power) is what counts. Choices aren't (often) only to do with technical superiority which may relate to requirements that I don't have.

> .... 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.

 

Yes, we come across this a lot when using XSD. The need for artificial <xsd:sequence> when in fact the element order is not critical (and then has a consequent impact on validation processing) and using <xsd:choice> or <xsd:all> does not help (XSD 1.1 might provide some help here but mainstream adoption is probably still some way off - and certainly is within the standards body that I am concerned with).

 

Of course, in these situations there isn't necessarily a need to have 'one true schema'. Application integration frequently involves mediation between the differing data models that are supported and can't be changed (for example: you may be using COTS application where you don't own the source). Maintaining fidelity is really the issue as you transform to and from each specific model. Most times this is possible, and if its not, its not going to be something that XSD or schematron are going to help with.

 

Fraser.

 

On 13/11/2007, Rick Jelliffe <rjelliffe@allette.com.au> wrote:

On Mon, 2007-11-12 at 15:40 -0500, noah_mendelsohn@us.ibm.com 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


_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php