[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XincaML


xincaml
From: "Bullard, Claude L (Len)" clbullar@i...

> 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

  • References:
    • XincaML
      • From: "Bullard, Claude L (Len)" <clbullar@i...>

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.