Lists Home |
Date Index |
From: "Bullard, Claude L (Len)" email@example.com
> XincaML - Is this a Schematron analog? It seems to
> fit into the same application space for contraint
Yes, it does seem to be another slice of the same pie as XLinkIt (UK), Schematron
(Taiwan/Australia) and XCSL (Portugal). Nice to see some work from IBM PRC:
it would be doubly nice to see some discussion relating to prior art -- what
problems their approach addresses that others do not, a nice dialog could only
improve ISO Schematron further. I guess that will appear in due course.
The distinctive feature of Schematron is not its paradigm (assertion based)
or its query language (Xpaths) but that it expresses patterns detected by rule chains
containing assertions, where each rule selects a disjoint set of candidate elements
and each assertion is an assertion about each candidate, and there is a lexical
priority between rules for candidate selection.
XincaML does not have patterns or rule chains, so it is not Schematron-like
from my view-point. Actually, without some abstract paradigm
(such as "pattern" or "element type") I would characterize it as a constraint
language or dispatch language rather than a schema language.
To see the difference, here is the Schematron
<pattern name="Co-occurrence Constraint">
<assert test="!(string-normalize(Role) = 'manager') or Manages" >
If the value of Role element is "manager", then the Manages element should be present.
<assert test="!managers or string-normalize(role) = 'manager' ">
If the Managers element is present, the value of the Role element should be "manager".
and here is the XincaML example from their documentation
<constraint name="managerConstraint" context="/userProfile">
<node id="role" location="role"/>
<node id="manages" location="/userProfile/manages"/>
<message> Manager only. </message>
The XincaML in the example does not actually implement the constraint
as specified earlier in their examples (hence the Schematron has two assertions,
and the XIncaML should probably be twice as large). Which would mean
the Schematron schema takes 3 elements while the XincaML would take
about 25+ elements.
Here are some other random comments:
1) I think an XincaML spec could be converted into a Schematron schema.
2) Their message element is equivalent to the Schematron <diagnostic> element,
but not shareable. However, they do not have any place, it seems, to mark up the natural
language assertion. I think this is a retrograde step, because it disconnects
intent from implementation.
3) It is interesting that XincaML has an explicit action section, which Schematron does not
have--that immediately ties it into a particular implementation language (i.e. it is a front
end for Java). When asked about an action element for Schematron, my approach has
been that it should be in a separate namespace, since it is implementation dependent.
That seems better layered, to me.
4) XincaML may be a little more declarative w.r.t. uniqueness. It may be useful to nick
their uniqueness element into Schematron, as a macro :-)
<unique value="@id" />
An id attribute should have a unique value
4) As a quibble, the XincaML schema is actually wrong (the names are
cased incorrectly). As I mentioned before, their example does not match
their spec given in their manual earlier: I think this is a general weakness in
other schema/constraint languages--people end up mentally substituting
the constraint *as implemented* with the constraint *as required*, and I
think good software engineering demands that specs and code be tied together.
Editor, ISO Schematron
- From: "Bullard, Claude L (Len)" <firstname.lastname@example.org>