Schema Specification of RuleML 0.89

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

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

Latest version: www.ruleml.org/spec

Quick links:

Content Models, Schemas (Archived DTDs), Normalizer, Upgrader, Examples


This is a revised XML Schema specification for RuleML, version 0.89. This release incorporates long-envisaged new expressiveness building upon the validation stable RuleML 0.88.

Each XML Schema Definition (XSD) in the evolving hierarchy corresponds to a specific RuleML sublanguage. The implementation uses a modularization approach similar to the one in XHTML in order to offer appropriate flexibility and accomodate 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.

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

For more information, see the Changes section.

The grammar of RuleML 0.89 (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. Issues relevant to RuleML 0.89 were already discussed in the Issues List of FOL RuleML, in particular issues 1. and 9.

A presentation entitled From RuleML 0.88 to 0.89: Sublanguages Beyond Horn Logic - Validation and Translation is also available.

See also a recent publication accepted for the W3C Rules Workshop in Washington: Implementing RuleML Using Schemas, Translators, and Bidirectional Interpreters.

Changes

RuleML 0.89 consists of the following changes relative to the previous version 0.88.

Four new sublanguages providing the modular specification of FOL RuleML have been added to the family:

Another three new sublanguages are also added to provide the serialization of the Semantic Web Services Language (SWSL):

A new tag <Reify> is introduced to support reification, a kind of instantiation or quasi-quotation. It is permitted anywhere a regular term (e.g. Ind or Var) is, in all sublanguages, and allows any RuleML tag available within the current sublanguage as content, treating it as a term for performing reasoning on. For example, the following is a reification of the 'own' rule:

 <Reify>
   <Implies>
     <And>
       <Atom>
         <Rel>buy</Rel>
         <Var>person</Var>
         <Var>merchant</Var>
         <Var>object</Var>
       </Atom>
       <Atom>
         <Rel>keep</Rel>
         <Var>person</Var>
         <Var>object</Var>
       </Atom>
     </And>
     <Atom>
       <Rel>own</Rel>
       <Var>person</Var>
       <Var>object</Var>
     </Atom>
   </Implies>
 </Reify>

See the SWSL report for more details on <Reify>.

Two new attributes 'minCard' and 'maxCard' are introduced to allow cardinality constraints on slots. For example, the following specifies that the cardinality of a slot is no less than 1 and no more than 2:

 <slot mincard="1" maxcard="2">...</slot>

Another important addition is <Data> that may optionally specify an XML Schema built-in datatype (e.g. date, integer, string) for checking during validation using the 'xsi:type' attribute. For example, the following are all correctly enforced during validation:

 <Data xsi:type="xs:string">test</Data>
 <Data xsi:type="xs:nonNegativeInteger">12</Data>
 <Data xsi:type="xs:dateTime">2002-10-10T17:00:00Z</Data>

And, as expected,

 <Data xsi:type="xs:short">10000000</Data>

fails, where XSV returns the following:

 <invalid char="1" code="cvc-complex-type.1.2.2" line="61" resource="file:///datalog.ruleml">
  element content failed type check: 10000000>32767
 </invalid>

Note that <Data> without an xsi:type attribute allows unrestricted text, as in RuleML Lite, and also that the following namespace declaration must be included to refer to XSD's built-in datatypes (as present in datalog.ruleml):

 xmlns:xs="http://www.w3.org/2001/XMLSchema"

Finally, note that other terms (e.g. Ind and Var) may only have user-defined types via the existing 'type' attribute. Ind roughly corresponds to resources in RDF, while Data corresponds with RDF literals.

Mutual exclusion is possible with the new <Mutex> tag, allowable as the first child of the new <Protect> performative (optionally wrapped by the <warden> role introduced to maintain RuleML's striped syntax). A <Mutex> states that it is a contradiction for a particular pair of literals (known as the "opposers" and denoted by "oppo") to be inferred, given another optional particular condition (known as the "given", marked up as "mgiv"). For example:

 <Mutex>
   <oppo>
     <And>
       <Hterm>
         <Con>pricediscount</Con>
         <Var>CUST</Var>
         <Var>Y</Var>
       </Hterm>
       <Hterm>
         <Con>pricediscount</Con>
         <Var>CUST</Var>
         <Var>Z</Var>
       </Hterm>
     </And>
   </oppo>
   <mgiv>
     <Neg>
       <Equal>
         <Var>Y</Var>
         <Var>Z</Var>
       </Equal>
     </Neg>
   </mgiv>
 </Mutex>

See Benjamin Grosof's Courteous Logic Programming for more details.

Introduced to Atoms (at hornlog), Cterms and Plex's are an optional positional rest role <repo> and a slotted rest role <resl>, both of which may only contain a Var or a Plex. For example:

 <Cterm>
   <Ctor>person</Ctor>
   <Var>who</Var>
   <repo><Var/></repo>
 </Cterm>

 <Cterm>
   <Ctor>person</Ctor>
   <slot><Ind>age</Ind><Var>age</Var></slot>
   <resl><Var>X</Var></resl>
 </Cterm>

With the new <Skolem> term (available in all sublanguages), RDF blank nodes can be captured as Skolem individual constants. For example, POSL's _PeterMillerPC becomes

 <Skolem>PeterMillerPC</Skolem>

and Skolem generator '_' becomes

 <Skolem/>

Object identifiers (<oid>) are now permitted in all atoms, connectives and quantifiers, now available for the first time in all instances of And (not just directly under Assert), Or, Naf and Neg.

The 'innerclose' attribute is renamed to 'mapClosure', and an analogous 'mapDirection' attribute is introduced. The new naming convention reflects attribute 'mapping' through XML trees as with

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

basically acting like

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

Webizing is optionally included in all sublanguages, eliminating the need for the entire 'ur' branch of the family of languages. However, bindatalog, bindatagroundlog and bindatagroundfact remain for the time being. See the updated modularization model for a clearer picture.

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 a fact asserting that John sells XMLBible to Mary:

 <Atom>
   <opr>
     <Rel>sell</Rel>
   </opr>
   <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.88.

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.

Modularization

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

The modularization used for Versions 0.7 and 0.8 was inverted in RuleML 0.85 to be more intuitive. The motivating factors behind this switch were simplicity (a single root with two distinct branches), consistency (inheritance in a single direction, for obvious super/subclass relationships) and efficiency (non-redundant implementation).

However, a limitation within XML Schema prevented this approach from being easily implemented (resulting in the unstable XSDs in 0.85), so the modularization was re-analyzed. This updated model reflects both the -- now fully-validating -- (XSD) implementation and expressiveness layering of RuleML, simultaneously capturing both the abstract and concrete.

Content Model-Based Approach

DTDs have limited support for modularity, but it can be achieved in a roundabout way using macro-like parameter entities. In particular, the contents of an external file can be included using an externally-linked parameter entity. For example, the following includes the contents of datalog.dtd:

<!ENTITY % datalog_include SYSTEM "datalog.dtd">
%datalog_include;

Simple inclusion is not enough, though: overriding is also necessary. Previously, this was managed using INCLUDE/IGNORE sections: the section that declared the element which had to be changed was simply IGNOREd, then the element was re-declared.

In version 0.85, this clumsy method of overriding was replaced with a much more elegent solution wherein every element's content model was explicitly defined by a parameter entity. The rulebase label '_rbaselab' (now 'oid'), for example, became declared as follows:

<!ENTITY % _rbaselab.content "(ind)"> 
<!ELEMENT _rbaselab %_rbaselab.content;>

Since parameter entities can overwrite one another (even across files), this content model could be easily replaced with another specified in a different DTD altogether, much like re-assigning a global variable in traditional programming languages. For example, the content model of the rulebase label '_rbaselab' is just "(ind)" in urcbindatagroundfact.dtd (as above), but was extended to permit a complex term (thus, becoming "(ind | cterm)") in hornlog.dtd:

<!ENTITY % _rbaselab.content "(ind | cterm)">

(Note that this overriding entity must be defined before the inclusion of other files.)

A visual demonstration of this process can be found on slide 25 of the Object-Oriented RuleML: Re-Modularized and XML Schematized via Content Models presentation.

The content model-based approach to modularization also works for XML Schema, using groups (and attributeGroups) instead of parameter entities. For example (now using 0.88 syntax, where '_rbaselab' is now 'oid'),

<!ENTITY % oid.content "(ind)"> 
<!ELEMENT oid % oid.content;>

becomes

<xs:attributeGroup name="oid.attlist"/>
<xs:group name="oid.content">
  <xs:choice>
    <xs:element name="Ind" type="Ind-oid.type"/>
  </xs:choice>
</xs:group>
<xs:complexType name="oid.type">
  <xs:group ref="oid.content"/>
  <xs:attributeGroup ref="oid.attlist"/>
</xs:complexType>
<xs:element name="oid" type="oid.type"/>

There is no need for workarounds in XSD: <redefine> makes the specified changes and includes everything else. For example,

<!ENTITY % oid.content "(ind | cterm)">

<!ENTITY % include SYSTEM "datalog.dtd">
%include;

becomes

<xs:redefine schemaLocation="datalog.xsd">
  <xs:group name="oid.content">
    <xs:choice>
      <xs:group ref="oid.content"/>
      <xs:element ref="Cterm"/>
    </xs:choice>
  </xs:group>
</xs:redefine>

XSDs

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

Examples

Numerous sample RuleML documents have been prepared and maintained as examples and for testing purposes. They are stored in the Examples directory. (Examples from previous versions of RuleML are also maintained, e.g. 0.88 examples).

XSLT-Based Upgrader

Continuing the practice begun in 0.86, an XSLT stylesheet named 088-to-089.xslt has been created to automatically update RuleML 0.88 documents to 0.89. For instance, taking the own example from 0.88 as input, the stylesheet outputs the following: own-089.ruleml. (See a comparison of these two files generated using HTML Diff, noting that the differences are minor since 0.89 mostly builds on top of 0.88.) Additional translation output samples are found in the Upgrader directory.

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.89/exa/ 0.88/exa/ 088-to-0.89.xslt

The stylesheet has also been tested using XML Spy (version 2005 sp3).

XSLT-Based Normalizer

An XSLT stylesheet has been developed (089_normalizer.xslt) for normalizing the syntax used in a given RuleML 0.89 instance, reconstructing all skipped role tags to be in a fully-expanded, normal form. For example, the compact version of the 'own' example,

<Assert>
  <And mapClosure="universal">
    <Implies>
      <And>
        <Atom>
          <Rel>buy</Rel>
          <Var>person</Var>
          <Var>merchant</Var>
          <Var>object</Var>
        </Atom>
        <Atom>
          <Rel>keep</Rel>
          <Var>person</Var>
          <Var>object</Var>
        </Atom>
      </And>
      <Atom>
        <Rel>own</Rel>
        <Var>person</Var>
        <Var>object</Var>
      </Atom>
    </Implies>
    ...
    <Atom>
      <Rel>keep</Rel>
      <Ind>Mary</Ind>
      <Ind>XMLBible</Ind>
    </Atom>
  </And>
</Assert>

is normalized to the expanded version:

<Assert>
  <content>
    <And innerclose="universal">
      <formula>
        <Implies>
          <body>
            <And>
              <formula>
                <Atom>
                  <opr><Rel>buy</Rel></opr>
                  <arg index="1"><Var>person</Var></arg>
                  <arg index="2"><Var>merchant</Var>	</arg>
                  <arg index="3"><Var>object</Var></arg>
                </Atom>
              </formula>
              <formula>
                <Atom>
                  <opr><Rel>keep</Rel></opr>
                  <arg index="1"><Var>person</Var></arg>
                  <arg index="2"><Var>object</Var></arg>
                </Atom>
              </formula>
            </And>
          </body>
          <head>
            <Atom>
              <opr><Rel>own</Rel></opr>
              <arg index="1"><Var>person</Var></arg>
              <arg index="2"><Var>object</Var></arg>
            </Atom>
          </head>
        </Implies>
      </formula>
      ...
      <formula>
        <Atom>
          <opr><Rel>keep</Rel></opr>
          <arg index="1"><Ind>Mary</Ind></arg>
          <arg index="2"><Ind>XMLBible</Ind></arg>
        </Atom>
      </formula>
    </And>
  </content>
</Assert>

(See a comparison of these two files generated using HTML Diff.)

Additional examples are located in the Normalizer directory.

Validation

To ensure validation stability, the 0.89 XSDs are tested (using corresponding instance documents/examples) with a selection of the most reliable validators. A summary of these validation results follows:

W3C XML Schema Validator (XSV) v 2.10-1
All examples and schemas validate perfectly except for the binary sublanguages due to a known bug introduced since 2.7-1.

Saxon v SA 8.4
All examples and schemas validate perfectly. Sample output:

 java com.saxonica.Validate -t http://www.ruleml.org/0.89/exa/own.ruleml
 Saxon-SA 8.4 from Saxonica
 Java version 1.5.0_03
 Processing http://www.ruleml.org/0.89/exa/own.ruleml
 Loading schema document http://www.ruleml.org/0.89/xsd/datalog.xsd
 Loading schema document http://www.ruleml.org/0.89/xsd/modules/performative_module.xsd
 Finished loading schema document http://www.ruleml.org/0.89/xsd/modules/performative_module.xsd
 Loading schema document http://www.ruleml.org/0.89/xsd/modules/desc_module.xsd
 Finished loading schema document http://www.ruleml.org/0.89/xsd/modules/desc_module.xsd
 Loading schema document http://www.ruleml.org/0.89/xsd/modules/quantifier_module.xsd
 Finished loading schema document http://www.ruleml.org/0.89/xsd/modules/quantifier_module.xsd
 Loading schema document http://www.ruleml.org/0.89/xsd/modules/connective_module.xsd
 Finished loading schema document http://www.ruleml.org/0.89/xsd/modules/connective_module.xsd
 Loading schema document http://www.ruleml.org/0.89/xsd/modules/atom_module.xsd
 Finished loading schema document http://www.ruleml.org/0.89/xsd/modules/atom_module.xsd
 Loading schema document http://www.ruleml.org/0.89/xsd/modules/slot_module.xsd
 Finished loading schema document http://www.ruleml.org/0.89/xsd/modules/slot_module.xsd
 Loading schema document http://www.ruleml.org/0.89/xsd/modules/term_module.xsd
 Finished loading schema document http://www.ruleml.org/0.89/xsd/modules/term_module.xsd
 Loading schema document http://www.ruleml.org/0.89/xsd/modules/ur_module.xsd
 Finished loading schema document http://www.ruleml.org/0.89/xsd/modules/ur_module.xsd
 Finished loading schema document http://www.ruleml.org/0.89/xsd/datalog.xsd
 Execution time: 1022 milliseconds

Appendix

Appended below is the XML Schema (version 0.89) for the Datalog sublanguage of RuleML (Appendix 1). Also appended below is a simple example rulebase that conforms to that XSD (Appendix 2), and instructions for how to validate the example against the schema (Appendix 3).

The entire family of 0.89 XSDs, specified in a modular fashion, are available here: http://www.ruleml.org/0.89/xsd. The XSD files in the main directory represent actual sublanguages of RuleML, whereas those in the modules subdirectory are elementary components included in the main XSDs. For more information, see the Modularization section.

More sample files -- each referring to the most specific XSD which validates it -- can be found at http://www.ruleml.org/0.89/exa.

Appendix 1: XSD for a Datalog subset of RuleML

Source: datalog.xsd

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

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

	<xs:annotation>
		<xs:documentation xml:lang="en">
			XML Schema for a Datalog RuleML sublanguage
			File: datalog.xsd
			Version: 0.89
			Last Modification: 2005-05-26
		</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
		* mutex
		* ur

		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/mutex_module.xsd"/>
	<xs:include schemaLocation="modules/ur_module.xsd"/>

</xs:schema>

Appendix 2: Example rulebase in RuleML

Source: own.ruleml

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

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

<!-- 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~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                 *     |     |           |                                   |
             opr *     |     |           |                                   |
                 *     |     |           |                                   |        
                Rel   Var   Var        Atom~~~~~~~~~~~~~~~~~~~~~~~~~~~     Atom~~~~~~~~~~~~~~~~~~
                 .     .     .                  *     |      |       |              *     |     |
                 .     .     .              opr *     |      |       |          opr *     |     |
                 .     .     .                  *     |      |       |              *     |     |
                own  person object             Rel   Var    Var     Var            Rel   Var   Var
                                                .     .      .       .              .     .     . 
                                                .     .      .       .              .     .     .
                                                .     .      .       .              .     .     .
                                               buy  person merchant object        keep  person object

... end XML comment -->

<And mapClosure="universal">

<Implies>
  <head>
    <Atom>
      <opr><Rel>own</Rel></opr>
      <Var>person</Var>
      <Var>object</Var>
    </Atom>
  </head>
  <body>
    <!-- explicit 'And' -->
    <And>
      <Atom>
        <opr><Rel>buy</Rel></opr>
        <Var>person</Var>
        <Var>merchant</Var>
        <Var>object</Var>
      </Atom>
      <Atom>
        <opr><Rel>keep</Rel></opr>
        <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>
      <opr><Rel>buy</Rel></opr>
      <Var>person</Var>
      <Var>merchant</Var>
      <Var>object</Var>
    </Atom>
  </head>
  <body>
    <Atom>
      <opr><Rel>sell</Rel></opr>
      <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>
      <opr><Rel>sell</Rel></opr>
      <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). Some of the
DTD's on the RuleML website handle URL's/URI's (UR's); see especially
urc-datalog.dtd for inferencing with RDF-like facts -->
 
    <Atom>
      <opr><Rel>keep</Rel></opr>
      <Ind>Mary</Ind>
      <Ind>XMLBible</Ind>
    </Atom>

</And>
  
</Assert>

Appendix 3: Instructions on validating the example against the XSD

Validating a RuleML 0.88 Sample Document: own.ruleml
====================================================

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.89/exa/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.89/exa/own.ruleml
       (Real name: http://www.ruleml.org/0.89/exa/own.ruleml
        Length: 3817 bytes
        Last Modified: Wed, 25 May 2005 18:42:42 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.89/xsd}Assert
  • Validation was strict, starting with type {http://www.ruleml.org/0.89/xsd}:Assert.type
  • schemaLocs: http://www.ruleml.org/0.89/xsd -> http://www.ruleml.org/0.89/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.89/xsd/datalog.xsd (source: schemaLoc) for http://www.ruleml.org/0.89/xsd, succeeded

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

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

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

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

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

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

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

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

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



Site Contact: Harold Boley. Page Version: 2005-07-14


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