Schema Specification of RuleML 0.91

David Hirtle, Harold Boley, Benjamin Grosof, Michael Kifer,
Michael Sintek, Said Tabet, Gerd Wagner, Tara Athan

Version history:

2001-01-25 - Version 0.7
2001-07-11 - Version 0.8
2003-12-09 - Version 0.85
2004-06-23 - Version 0.86
2004-08-12 - Version 0.87
2005-03-01 - Version 0.88
2005-05-27 - Version 0.89
2005-11-09 - Version 0.9
2006-08-24 - Version 0.91

2011-09-27 -

Version 0.91 Patched

Latest version: www.ruleml.org/spec

Quick links:

Content Models, Schemas, Examples, Glossary, Errata


This is the revised XML Schema specification (including Schematron annotations) for RuleML version 0.91, now incorporating Functional RuleML.

Each XML Schema Definition (XSD) in the evolving hierarchy corresponds to a specific RuleML sublanguage. The implementation uses a content-model based modularization approach in order to offer appropriate flexibility and accommodate different implementations and approaches. Note that the Document Type Definition (DTD) specification of RuleML is no longer being maintained, but will continue to be available as an archive. Tools capable of converting between XML Schema and DTDs such as XMLSpy are always available.

Contents

Overview

An introduction to RuleML is given in our tutorial. Also, the main page's design section discusses the upper layer of the RuleML hierarchy of rules. In that terminology, the system of RuleML XSDs presented here only covers derivation rules, not reaction rules (see the official model).

This is because we think it is important to start with a subset of simple rules, test and refine our principal strategy using these, and then work 'up' to the more general categories of rules in the hierarchy. For this we choose Datalog, a language corresponding to relational databases (ground facts without complex domains or 'constructors') augmented by views (possibly recursive rules), and work a few steps upwards to further declarative rules as allowed in (equational) Horn logic.

Below is a summary of the changes in version 0.91:

For more information, see the Patches and Changes section.

A comprehensive glossary accompanies this specification.

The grammar of RuleML 0.91 (i.e. the content model of each individual tag) is available as a single document called Content Models for RuleML in addition to being encoded within the XML Schemas.

An XML Schema version of RuleML 0.91 generated from Relax NG is being developed at RuleML 0.91 in Relax NG.

Patches

A patch to the 0.91 release was applied on May 14, 2011 to correct several of the errors identified during the re-engineering of the schema into Relax NG syntax. The patch details are given at Errata.

Changes

Changes in this 0.91 release relative to the previous version 0.9 are detailed below, including examples where appropriate.

It was a RuleML issue up to version 0.9 that the constructor (<Ctor>) of a complex term (<Cterm>) was disjoined, as an XML element, from the user-defined function (<Fun>) of a call expression (<Nano>), although these can be merged by proceeding to a logic with equality. While function-defining <Nano> patterns could contain <Cterm>s but not <Nano>s, obeying the 'constructor discipline', <Nano>s could also be permitted within <Nano>s to legalize 'optimization' rules like reverse(reverse(?L)) = ?L.

Functional RuleML thus conceives both <Cterm>s and <Nano>s as expression (<Expr>) elements and distinguishes uninterpreted (constructor) vs. interpreted (user-defined) functions just via an XML attribute @in={"no","yes"}.

For example, a function first-born(John, Mary) can be uninterpreted, so that first-born(John, Mary) just denotes the first-born child; or, interpreted, e.g. using definition first-born(John, Mary) = Jory, so the application first-born(John, Mary) returns Jory. Such interpreted and uninterpreted functions are both allowed in Functional RuleML, and are marked up here with a discriminating interpreted attribute @in as follows:

 <Expr>
   <Fun in="yes">first-born</Fun>
   <Ind>John</Ind>
   <Ind>Mary</Ind>
 </Expr>

and

 <Expr>
   <Fun in="no">first-born</Fun>
   <Ind>John</Ind>
   <Ind>Mary</Ind>
 </Expr>

Note that as a result of the above change, <Ctor> is no longer necessary as it is now always <Fun>.

<Entails> is introduced for logical entailment (conventionally indicated by the "|-" symbol) where the first child entails the second, both being <Rulebase>s. When <Assert>ed, this effectively replaces 0.9's <Protect> and renders the explicit <Integrity> tag unnecessary since integrity constraints are just formulas (in the second <Rulebase>) used in an integrity-maintaining way. So instead of

 <Protect>
   <Integrity><And>ic1 . . . icM</And></Integrity>
   <And>clause1 . . . clauseN</And>
 </Protect>

we obtain ("Assert that the knowledge base entails the integrity constraints"):

 <Assert>
   <Entails>
     <Rulebase>clause1 . . . clauseN</Rulebase>
     <Rulebase>ic1 . . . icM</Rulebase>
   </Entails>
 </Assert>

More concretely, with 'implicit <And>' assumptions, the inconsistency of a watch being both gold and rusty, in 0.9

 <Protect>
   <Integrity>
     <Neg>
       <And>
         <Atom>
           <Rel>gold</Rel>
           <Var>object</Var>
         </Atom>
         <Atom>
           <Rel>rusty</Rel>
           <Var>object</Var>
         </Atom>       
       </And>
     </Neg>
   </Integrity>
   <Atom>
     <Rel>gold</Rel>
     <Ind>watch17</Ind>
   </Atom>
   <!-- inconsistent -->
   <Atom>
     <Rel>rusty</Rel>
     <Ind>watch17</Ind>
   </Atom>
 </Protect>

is as follows in 0.91:

 <Assert>
   <Entails>
     <Rulebase>
       <Atom>
         <Rel>gold</Rel>
         <Ind>watch17</Ind>
       </Atom>
       <!-- inconsistent -->
       <Atom>
         <Rel>rusty</Rel>
         <Ind>watch17</Ind>
       </Atom>
     </Rulebase>
     <Rulebase>
       <Neg>
         <And>
           <Atom>
             <Rel>gold</Rel>
             <Var>object</Var>
           </Atom>
           <Atom>
             <Rel>rusty</Rel>
             <Var>object</Var>
           </Atom>       
         </And>
       </Neg>
     </Rulebase>
   </Entails>
 </Assert>

Since <Rulebase>, as an unordered or ordered collection of rules with or without duplicates, is more general than <And> (always unordered, without duplicates), the 'implicit <And>' assumption now becomes an 'implicit <Rulebase>' assumption. So 0.9's

 <Assert>
   <And>
     ...
   <And>
 </Assert>

is instead

 <Assert>
   <Rulebase>
     ...
   <Rulebase>
 </Assert>

in 0.91, which is equivalent to

 <Assert>
   ...
 </Assert>

because of the 'implicit <Rulebase>' assumption.

With the addition of the <Retract> performative (syntactically identical to <Assert>), rulebase assertions can be "removed". For example, if John no longer likes Mary (after an argument, perhaps) then this fact could be retracted:

 <Retract>
   <Atom>
     <Rel>likes</Rel>
     <Ind>John</Ind>
     <Ind>Mary</Ind>
   </Atom>
 </Retract>

The <Data> element, already introduced in version 0.89 to support XML Schema built-in datatypes, now also allows arbitrary XML (in addition to unrestricted text) when a datatype is not specified using the 'xsi:type' attribute. For example, this XML about some kind of object can now be treated as data within an <Atom>:

 <Data>   
   <ex:object>
     <ex:id>115897</ex:id>
     <ex:owner>John Doe</ex:owner>
   </ex:object>
 </Data>

Also introduced in 0.89, the <Reify> element was initially too permissive in that it allowed any valid XML instead of being restricted to valid RuleML (within the specified sublanguage). This has been corrected, so that, e.g., while

 <Reify><Ind>John Doe</Ind></Reify>
is valid, the following is not valid RuleML even if it is valid according to the schema for its namespace:

 <Reify>   
   <ex:object>
     <ex:id>115897</ex:id>
     <ex:owner>John Doe</ex:owner>
   </ex:object>
 </Reify>

The new @mapMaterial attribute has been introduced to complement the (renamed) @material attribute (previously @kind) in the same way as @mapClosure and @mapDirection. (See Attribute Mapping for more information on this "mapping" convention.) So a "first order" (classical) rule from 0.9

 <Implies kind="fo">
   ...
 </Implies>

is represented as follows in 0.91:

 <Implies material="yes">
   ...
 </Implies>

Conversely, "logic programming" (kind="lp" in 0.9) implication is now indicated by material="no".

An equation (<Equal>) can now have an @oriented attribute for indicating whether it is oriented (directed) or unoriented (symmetric). For example, the (oriented) defining equation home(father-of(John)) = Mexico City appears as follows:

 <Equal oriented="yes">
   <lhs>
     <Expr>
       <Fun in="yes">home</Fun>
       <Expr>
         <Fun in="no">father-of</Fun>
         <Ind>John</Ind>
       </Expr>
     </Expr>
   </lhs>
   <rhs>
     <Ind>Mexico City</Ind>
   </rhs>
 </Equal>

Note also that the <side> role tag from 0.9 has been split into separate <lhs> and <rhs> tags in 0.91.

Since interpreted functions are often set-valued (non-deterministic), a @val attribute is introduced in Functional RuleML with values including "1" (deterministic: exactly one) and "0.." (set-valued: zero or more). For example, the function children(John, Mary) can be interpreted in a set-valued manner using a definition children(John, Mary) = {Jory, Mahn}, so that the application children(John, Mary) returns {Jory, Mahn}. In 0.91, the example is marked up as follows:

 <Expr>
   <Fun in="yes" val="0..">children</Fun>
   <Ind>John</Ind>
   <Ind>Mary</Ind>
 </Expr>

Examples

Numerous sample RuleML documents have been prepared and maintained; some exemplify features of RuleML and are useful didactically while others are mostly for testing puposes. Four new examples (ackermann.ruleml, functional.ruleml, reify.ruleml and ssn.ruleml) accompany the 0.91 release and can be found with all the others in the Examples directory.

Examples from previous versions of RuleML are also maintained, e.g. 0.9 examples).

XSLT-Based Upgrader

Continuing the practice begun in 0.86, an XSLT stylesheet named 090-to-091.xslt has been created to automatically update RuleML 0.9 documents to 0.91. For instance, taking the discount example from 0.9 as input, the stylesheet outputs the following: discount_91.ruleml. (See a comparison of these two files generated using HTML Diff, noting that the differences are minor.) Additional translation output samples are found in the Upgrader directory. In the comparison directory a comparison between manual and automatic updates of a few files from the 0.9 exa directory can be found.

It should be noted that -- since there are changes in RuleML 0.91 that limit the content of some elements compared to RuleML 0.9 -- some RuleML 0.9 documents cannot be automatically converted to valid RuleML 0.91 files. In such cases, the 0.9-0.91 upgrader can still be used; however, some manual post-editing is required to make the files valid with respect to the RuleML 0.91 XSD schema. Namely, the relevant changes between RuleML 0.9 and RuleML 0.91 are the following:

More information about these changes can be found in 0.91 Changes section.

Upgrader transformation can be accomplished using a web-based XSLT transformation tool provided by W3C. Instructions for this process can be found in Appendix 4.

The stylesheet has also been tested using XML Spy.

An XSLT processor which may be used to perform these transformations on a whole directory at once is Saxon, using the following command:

$ java net.sf.saxon.Transform -o 0.91/exa/ 0.9/exa/ 090-to-091.xslt

Glossary

The glossary for RuleML 0.91 contains descriptions for every tag in RuleML 0.91.

Modularization

The most current model of the modularization of RuleML is always documented at http://www.ruleml.org/modularization/#Model.

XSDs

A stable XML Schema specification of RuleML 0.91 has been created using an approach that is consistent with that used in the (version 0.85) DTDs.

Schematron

Starting with RuleML 0.91, Schematron is used for additional constraints that are either difficult or impossible to enforce using only XML Schema. This approach has the benefit of reducing complexity in the XSDs, making them more maintainable by avoiding dependence on "XSD tricks" to achieve context-sensitivity.

As explained in the official overview, "The Schematron differs in basic concept from other schema languages in that it not based on grammars but on finding tree patterns in the parsed document. This approach allows many kinds of structures to be represented which are inconvenient and difficult in grammar-based schema languages." A Schematron article also points out that XML Schema was not designed to meet all XML validation needs in the first place; in fact, the specification states: "However, the language defined by this specification does not attempt to provide all the facilities that might be needed by any application. Some applications may require constraint capabilities not expressible in this language, and so may need to perform their own additional validations."

The use of Schematron in RuleML allows, for example, enforcing that a defining equality (i.e. an <Equal> in the head of an <Implies>) must have an interpreted left hand side (i.e. <Fun in="yes">...<Fun>):

<sch:rule context=
  "r:Implies/r:head/r:Equal/r:lhs/r:Expr/r:Fun |
  r:Implies/r:Equal[2]/r:lhs/r:Expr/r:Fun | 
  r:Implies/r:head/r:Equal/r:Expr[1]/r:Fun | 
  r:Implies/r:Equal[2]/r:Expr[1]/r:Fun">
  <sch:assert test="@in='yes'">
    A defining equality must have an interpreted left-hand side.
  </sch:assert>
</sch:rule>

This constraint makes the following rule invalid, even though it is valid with respect to the XSDs:

<Implies>
  <Atom>
    <Rel>greaterThanOrEqual</Rel>
    <Expr>
      <Fun in="yes">this-year</Fun>
    </Expr>
    <Data>1993</Data>
  </Atom>
  <Equal>
    <lhs>
      <Expr>
        <Fun in="no">age</Fun>   <!-- @in must equal "yes" -->
        <Expr>
          <Fun in="no">first-born</Fun> 
          <Ind>John</Ind>
          <Ind>Mary</Ind>
        </Expr>
      </Expr>
    </lhs>
    <rhs>
      <Expr>
        <Fun in="yes">subtract</Fun>
        <Expr>
          <Fun in="yes">this-year</Fun>
        </Expr>
        <Data>1993</Data>
      </Expr>
    </rhs>
  </Equal>
</Implies>

The Schematron constraints for RuleML 0.91 are embedded in the relevant XSD modules as annotations (e.g. the one above is in the equality module) but are also available collected into a single schema (ruleml.sch). A public XSLT stylesheet called XSD2Schtrn.xsl can be used to create ruleml.sch by extracting all embedded Schematron constraints from the XSDs.

Schematron's ease of use, being based on XSLT, has led to numerous implementations. For RuleML, we use Academia Sinica Schematron 1.5. All essential files are available in the Schematron directory, along with a batch file (validate.bat) that performs both XSV and Schematron validation on a RuleML document (after extracting Schematron constraints embedded in the XSDs).

See Appendix 4 for instructions on validating an example with Schematron using W3C's Online XSLT 2.0 Service.

Validation

To ensure validation stability, the 0.91 XSDs are tested (using corresponding instance documents/examples) with the W3C XML Schema Validator (XSV) (currently version 2.10-1). If using the locally-installed version of XSV, a simple batch file called xsvall.bat can be downloaded and used to validate all examples in the current directory, displaying the results in a conveniently summarized format.

All 0.91 examples and schemas validate perfectly except for the binary sublanguages. There was a related known bug in XSV 2.7-1 affecting the binary sublanguages that may still be causing problems. The issue has been (re-)reported to the xmlschema-dev mailing list.

Note that the "Recognised as RDDL, but no W3C XML Schema resource found" warning can safely be ignored; it only appears because Schematron rules are embedded within the XSDs.

Full compliance to the RuleML 0.91 specification involves both XML Schema and Schematron validation, the latter acting as a kind of "semantic validation". A batch file (validate.bat) is available for performing both XSV and Schematron validation on a RuleML document.

See Appendix 3 for instructions on validating an example against its XML Schema and Appendix 4 for instructions on validating an example with Schematron using W3C's Online XSLT 2.0 Service.

Striped Syntax

There are two kinds tags in RuleML: method-like 'role' tags and class-like 'type' tags. The two are easily distinguished by their initial letter, much like the convention used in Java: role tags start with a lower-case letter, whereas type tags start with an upper-case letter. For example, <head> is a role tag and <Ind> is a type tag.

Furthermore, type and role tags alternate in RuleML. For example, notice the alternation in this fact asserting that John sells XMLBible to Mary:

 <Atom>
   <op>
     <Rel>sell</Rel>
   </op>
   <arg index="1">
     <Ind>John</Ind>
   </arg>
   <arg index="2">
     <Ind>Mary</Ind>
   </arg>
   <arg index="3">
     <Ind>XMLBible</Ind>
   </arg>
 </Atom>

This is known as the "striped syntax" of RuleML, and is important for compatibility with RDF. Because this is quite verbose, all role tags can also be skipped (in the spirit of Sandro Hawke's StripeSkipping), leaving a more compact form. For example, the above fact can be shortened to:

 <Atom>
   <Rel>sell</Rel>
   <Ind>John</Ind>
   <Ind>Mary</Ind>
   <Ind>XMLBible</Ind>
 </Atom>

Note that there is no loss of information, because all role tags can be reconstructed based on the remaining type tags. In fact, this reconstruction (from the latter positional form to the former slotted form) can be done automatically via XSLT, as with the Normalizer in 0.89.

This gives the syntax of RuleML a lot of flexibility because it allows either a compact or expanded form (or any combination thereof), where the compact form is more user-friendly and the expanded (normalized) form is more compatible with other languages.

Attribute Mapping

There are three pairs of attributes in RuleML that have names which differ only by a 'map' prefix: closure and mapClosure, direction and mapDirection, and material and mapMaterial. The naming convention reflects attribute 'mapping' through XML trees, where

<TypeTag mapAttribute="..."><c1>. . .</c1>. . .<cN>. . .</cN></TypeTag>

basically acts like

<TypeTag><c1 attribute="...">. . .</c1>. . .<cN attribute="...">. . .</cN></TypeTag>

Appendix

Appended below are a simple example rulebase (Appendix 1), the XML Schema for the Datalog sublanguage of RuleML to which the rulebase conforms (Appendix 2), instructions for how to validate the example against the schema (Appendix 3) and instructions on validating the example with Schematron (Appendix 4).

Appendix 1: Example rulebase in RuleML

Source: own.ruleml

<?xml version="1.0" encoding="UTF-8"?>

<RuleML
xmlns="http://www.ruleml.org/0.91/xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.ruleml.org/0.91/xsd http://www.ruleml.org/0.91/xsd/datalog.xsd"
>

<Assert mapClosure="universal">

<!-- start XML comment ...

This example rulebase contains four rules.
The first and second rules are implications; the third and fourth ones are facts.

In English:

The first rule implies that a person owns an object
if that person buys the object from a merchant and the person keeps the object.

As an OrdLab Tree:

Implies~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          *                         *
     head *                    body *
          *                         *
        Atom~~~~~~~~~~~~~~~~~~     And~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                 *     |     |           |                                   |
             op  *     |     |           |                                   |
                 *     |     |           |                                   |        
                Rel   Var   Var        Atom~~~~~~~~~~~~~~~~~~~~~~~~~~~     Atom~~~~~~~~~~~~~~~~~~
                 .     .     .                  *     |      |       |              *     |     |
                 .     .     .              op  *     |      |       |          op  *     |     |
                 .     .     .                  *     |      |       |              *     |     |
                own  person object             Rel   Var    Var     Var            Rel   Var   Var
                                                .     .      .       .              .     .     . 
                                                .     .      .       .              .     .     .
                                                .     .      .       .              .     .     .
                                               buy  person merchant object        keep  person object

... end XML comment -->

<Implies>
  <head>
    <Atom>
      <op><Rel>own</Rel></op>
      <Var>person</Var>
      <Var>object</Var>
    </Atom>
  </head>
  <body>
    <!-- explicit 'And' -->
    <And>
      <Atom>
        <op><Rel>buy</Rel></op>
        <Var>person</Var>
        <Var>merchant</Var>
        <Var>object</Var>
      </Atom>
      <Atom>
        <op><Rel>keep</Rel></op>
        <Var>person</Var>
        <Var>object</Var>
      </Atom>
    </And>
  </body>
</Implies>

<!-- The second rule implies that a person buys an object from a merchant
if the merchant sells the object to the person. -->

<Implies>
  <head>
    <Atom>
      <op><Rel>buy</Rel></op>
      <Var>person</Var>
      <Var>merchant</Var>
      <Var>object</Var>
    </Atom>
  </head>
  <body>
    <Atom>
      <op><Rel>sell</Rel></op>
      <Var>merchant</Var>
      <Var>person</Var>
      <Var>object</Var>
    </Atom>
  </body>
</Implies>
 
 
<!-- The third rule is a fact that asserts that
John sells XMLBible to Mary. -->
 
    <Atom>
      <op><Rel>sell</Rel></op>
      <Ind>John</Ind>
      <Ind>Mary</Ind>
      <Ind>XMLBible</Ind>
    </Atom>

 
<!-- The fourth rule is a fact that asserts that
Mary keeps XMLBible.
 
Observe that this fact is binary - i.e., there are two arguments
for the relation. RDF viewed as a logical knowledge representation
is, likewise, binary, although its arguments have type restrictions,
e.g., the first must be a resource (basically, a URI). -->
 
    <Atom>
      <op><Rel>keep</Rel></op>
      <Ind>Mary</Ind>
      <Ind>XMLBible</Ind>
    </Atom>
  
</Assert>

</RuleML>

Appendix 2: XSD for the Datalog sublanguage of RuleML

Source: datalog.xsd

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema 
xmlns="http://www.ruleml.org/0.91/xsd" 
xmlns:xs="http://www.w3.org/2001/XMLSchema" 
targetNamespace="http://www.ruleml.org/0.91/xsd"
>

	<xs:annotation>
		<xs:documentation xml:lang="en">
			XML Schema for the RuleML sublanguage "datalog".
			File: datalog.xsd
			Version: 0.91
			Last Modification: 2006-07-19
		</xs:documentation>
	</xs:annotation>

	<!--
		Note that datalog is entirely composed of modules and that all other
		schema drivers rely on it, making it the root of the sublanguage family tree.
	-->

	<!--
		Datalog includes the following modules:
		* performative
		* desc
		* quantifier
		* connective
		* atom
		* slot
		* term
		* uri

		For details on each module, including what element and/or attribute declarations
		they contain, please refer to them individually.
	-->

	<xs:include schemaLocation="modules/performative_module.xsd"/>
	<xs:include schemaLocation="modules/desc_module.xsd"/>
	<xs:include schemaLocation="modules/quantifier_module.xsd"/>
	<xs:include schemaLocation="modules/connective_module.xsd"/>
	<xs:include schemaLocation="modules/atom_module.xsd"/>
	<xs:include schemaLocation="modules/slot_module.xsd"/>
	<xs:include schemaLocation="modules/term_module.xsd"/>
	<xs:include schemaLocation="modules/uri_module.xsd"/>

</xs:schema>

Appendix 3: Instructions on validating the example online with XSD

Validating a RuleML 0.91 Sample Document with XSV
=================================================

1. Direct your browser to 
http://www.w3.org/2001/03/webdata/xsv
(Validator for XML Schema REC (20010502) version, as amended).

2. Enter the following URL of our example RuleML file (or any other) into the textfield
preceded by "Address(es)": http://www.ruleml.org/0.91/exa/Datalog/own.ruleml

3. If desired, check the "Show Warnings" box.

4. Click the "Get Results" button.

Note: The validation may take a while, and may require a full
refresh when re-validating to avoid caching.

Also note: Depending on your browser, you may want to select a different
output using the radio buttons just above the "Get Results" button.

***
 
You should get the following output (using the default output):

Schema validating with XSV 2.10-1 of 2005/04/22 13:10:49

  • Target: http://www.ruleml.org/0.91/exa/Datalog/own.ruleml
       (Real name: http://www.ruleml.org/0.91/exa/Datalog/own.ruleml
        Length: 3675 bytes
        Last Modified: Wed, 23 Aug 2006 19:41:50 GMT
        Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) mod_fastcgi/2.4.2 mod_ssl/2.8.12 OpenSSL/0.9.6b DAV/1.0.3 PHP/4.1.2 mod_perl/1.26)
  • docElt: {http://www.ruleml.org/0.91/xsd}RuleML
  • Validation was strict, starting with type {http://www.ruleml.org/0.91/xsd}:RuleML.type
  • schemaLocs: http://www.ruleml.org/0.91/xsd -> http://www.ruleml.org/0.91/xsd/datalog.xsd
  • The schema(s) used for schema-validation had no errors
  • No schema-validity problems were found in the target

Schema resources involved

Attempt to load a schema document from http://www.ruleml.org/0.91/xsd/datalog.xsd (source: schemaLoc) for http://www.ruleml.org/0.91/xsd, succeeded

Attempt to load a schema document from http://www.ruleml.org/0.91/xsd/modules/performative_module.xsd (source: include) for http://www.ruleml.org/0.91/xsd, succeeded

Attempt to load a schema document from http://www.ruleml.org/0.91/xsd/modules/desc_module.xsd (source: include) for http://www.ruleml.org/0.91/xsd, succeeded

Attempt to load a schema document from http://www.ruleml.org/0.91/xsd/modules/quantifier_module.xsd (source: include) for http://www.ruleml.org/0.91/xsd, succeeded

Attempt to load a schema document from http://www.ruleml.org/0.91/xsd/modules/connective_module.xsd (source: include) for http://www.ruleml.org/0.91/xsd, succeeded

Attempt to load a schema document from http://www.ascc.net/xml/schematron (source: new namespace) for http://www.ascc.net/xml/schematron, failed:
Recognised as RDDL, but no W3C XML Schema resource found

Attempt to load a schema document from http://www.ruleml.org/0.91/xsd/modules/atom_module.xsd (source: include) for http://www.ruleml.org/0.91/xsd, succeeded

Attempt to load a schema document from http://www.ruleml.org/0.91/xsd/modules/slot_module.xsd (source: include) for http://www.ruleml.org/0.91/xsd, succeeded

Attempt to load a schema document from http://www.ruleml.org/0.91/xsd/modules/term_module.xsd (source: include) for http://www.ruleml.org/0.91/xsd, succeeded

Attempt to load a schema document from http://www.ruleml.org/0.91/xsd/modules/uri_module.xsd (source: include) for http://www.ruleml.org/0.91/xsd, succeeded


Appendix 4: Instructions on validating the example online with Schematron

Validating a RuleML 0.91 Sample Document with Schematron
========================================================

1. Direct your browser to 
http://www.w3.org/2005/08/online_xslt
(Online XSLT 2.0 Service).

2. Enter the following into the textfield preceded by "URI for xsl resource":
http://www.ruleml.org/schematron/schematron-ruleml.xsl

3. Enter the following URL of our example RuleML file (or any other) into the textfield
preceded by "URI for xml resource": http://www.ruleml.org/0.91/exa/Datalog/own.ruleml

4. Click the "transform" button.

***

You should get no output (since own.ruleml does not validate any Schematron constraints).

For a more interesting example, try http://www.ruleml.org/0.91/exa/Hornlog/hornlogeq.ruleml
as the xml resource, leaving the xsl resource the same.

You should now get the following output:

In pattern not(../r:Expr/r:Fun[@in='yes'] or ../r:arg/r:Expr/r:Fun[@in='yes']
or ../r:Expr/r:op/r:Fun[@in='yes'] or ../r:arg/r:Expr/r:op/r:Fun[@in='yes']):
Functions nested within an uninterpreted function must also be uninterpreted.

Site Contact: Tara Athan. Page Version: 2011-12-11


"Practice what you preach": XML source of this homepage at index.xml;
transformed to HTML via the adaptation of Michael Sintek's SliML XSLT stylesheet at homepage.xsl (View | Page Source)