Re: [xml-dev] XincaML

["Rick Jelliffe" <ricko@allette.com.au>]

From: "Bullard, Claude L (Len)" clbullar@ingr.com

> XincaML -  Is this a Schematron analog?  It seems to 
> fit into the same application space for contraint 
> validation.

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">
        <rule context="/userProfile">
            <assert test="!(string-normalize(Role) = 'manager') or Manages" >
            If the value of Role element is "manager", then the Manages element should be present. 
           </assert>
            <assert test="!managers or string-normalize(role) = 'manager' ">
            If the Managers element is present, the value of the Role element should be "manager".
            </assert>
        </rule>
    </pattern>

and here is the XincaML example from their documentation

<constraint name="managerConstraint" context="/userProfile">
        <if>
            <assert>
                <node id="role" location="role"/>
                <satisfy flag="true">
                    <ne>
                        <nodeValue ref="role"/>
                        <stringValue>manager</stringValue>
                    </ne>
                </satisfy>
            </assert>
        </if>
        <then>
            <assert>
                <node id="manages" location="/userProfile/manages"/>
                <present flag="false"/>
            </assert>
        </then>
        <action>
            <message> Manager only. </message>
        </action>
    </constraint>

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 :-)

<rule context="*[@id]">
    <unique value="@id" />
</rule>

expanding to 

<rule context="*[@id]">
    <assert test="count(*[@id][@id=current()/@id])=1">
        An id attribute should have a unique value
    </assert>
</rule>

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.

Cheers
Rick Jelliffe
Editor, ISO Schematron