Specification of RuleML 0.85
DTDs and XML Schemas Re-Modularized via Content Models

David Hirtle, Harold Boley, Carlos Damasio, Benjamin Grosof, Said Tabet, Gerd Wagner

Version History, 2001-01-25: Version 0.7
Version History, 2001-07-11: Version 0.8

Version History, 2003-12-09: Version 0.85

Latest version: www.ruleml.org/spec

All DTDs: DTD Directory

All Schemas: XSD Directory

Some Examples: Examples Directory


This is a revised DTD and preliminary XML Schema draft for RuleML. Each DTD and 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.

Contents

Overview

Version 0.85 continues the shift from positional to object-centered rule representation which began in Version 0.8, adding the following features:

A full discussion of (most of) these additions can be found in the Object-Oriented RuleML section. Further changes include re-modularization and a representation in XML Schema. Also note that n-tuple (tup) has been renamed (com)plex to accomodate unordered complex structures, and that role-list (roli) is now simulated by complex structures containing nothing but metaroles (_slot). As always, the DTDs etc. of previous versions (0.7, 0.8) will remain untouched, and can be considered as languages by themselves.

A presentation summarizing this work, entitled Object-Oriented RuleML: Re-Modularized and XML Schematized via Content Models (PDF), is also available.

Changes

First, two long-planned changes have now been officially incorporated: and/or nesting in the body and two kinds of negation. Also, non-positional user-level roles have been incorporated without duplicating the number of existing sublanguages. Finally, handles for term typing and URI-grounded clauses have been established as a couple of preliminary XML attributes.

Also, a few tags have been renamed: '_r' became '_slot', 'n' has been expanded to 'name', and 'w' is now 'weight'. This deviation from the earlier OO RuleML is the result of an attempt to increase readability.

Some of the OO DTD changes (namely, user-level roles via the metarole '_slot' and role weights via the attribute 'weight') are detailed in the OO RuleML section, but specific implementations are often more complex in order to comply with the XML 1.0 specification which prohibits non-determinististic (i.e. ambiguous) content models.

user level roles:

<!--
intuitively, the content model is
"((_opr, (_slot)*, (ind | var | cterm | plex)*, (_slot)*) | ((_slot)*, (ind | var | cterm | plex)+, (_slot)*, _opr))"
but this is non-deterministic
-->
<!ELEMENT atom (
                  ( _opr,
                    (_slot)*, ( (ind | var | cterm | plex)+, (_slot)*)?
                  ) 
                |
                  (
                     (
                        ((_slot)+, ( (ind | var | cterm | plex)+, (_slot)* )?)
                      |
                        ((ind | var | cterm | plex)+, (_slot)*)
                     ),
                     _opr
                  )
               )>

<!--
again, the content model is
"((_opc, (_slot)*, (ind | var | cterm | plex)*, (_slot)*) | ((_slot)*, (ind | var | cterm | plex)+, (_slot)*, _opc))"
but this is also ambiguous
-->
<!ELEMENT cterm (
                   ( _opc,
                     (_slot)*, ( (ind | var | cterm | plex)+, (_slot)*)?
                   ) 
                 |
                   (
                      (
                         ((_slot)+, ( (ind | var | cterm | plex)+, (_slot)* )?)
                       |
                         ((ind | var | cterm | plex)+, (_slot)*)
                      ),
                      _opc
                   )
                )>

<!ELEMENT plex (
                (_slot)*, ( (ind | var | cterm | plex)+, (_slot)* )?
              )>

<!ELEMENT _slot (ind | var | cterm | plex)>
<!ATTLIST _slot name CDATA #REQUIRED>
<!ATTLIST _slot card CDATA #IMPLIED>

URI-grounding:

<!-- Note: 'href' is only an example attribute, easily replaced with e.g. 'wid' and 'widref' -->
<!ATTLIST ind href CDATA #IMPLIED>
<!ATTLIST rel href CDATA #IMPLIED>
<!ATTLIST ctor href CDATA #IMPLIED>

term typing:

<!ATTLIST ind type CDATA #IMPLIED>
<!ATTLIST var type CDATA #IMPLIED>
<!ATTLIST cterm type CDATA #IMPLIED>

weighted extension:

<!ATTLIST _slot weight CDATA #IMPLIED>

These Version 0.85 modifications can be seen in the DTDs, as well as in the XML Schema representation. Validation instructions are included in each directory.

Re-Modularization

The modularization used for Versions 0.7 and 0.8 has been inverted and modified slightly to be more intuitive. This re-modularization aims at simplicity (a single root with two distinct branches), consistency (inheritance in a single direction, for obvious super/subclass relationships) and efficiency (non-redundant implementation). Note that currently non-standalone files called mods are used in the DTD implementation for changes affecting multiple files, but mods are not currently used in the XSD representation.

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 is handled much more elegantly. Every element's content model is explicitly defined by a parameter entity. The metarole '_slot', for example, is declared as follows:

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

Since parameter entities can overwrite one another (even across files), this content model is 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 metarole '_slot' is just "(ind)" in urcbindatagroundfact.dtd (as above), but is extended to permit a variable (thus, becoming "(ind | var)") in urcbindatalog.dtd:

<!ENTITY % _slot.content "(ind | var)">

(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,

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

becomes

<xs:attributeGroup name="_slot.attlist"/>
<xs:group name="_slot.content">
   <xs:sequence>
      <xs:element ref="ind"/>
   </xs:sequence>
</xs:group>
<xs:complexType name="_slot.type" mixed="true">
   <xs:group ref="_slot.content"/>
   <xs:attributeGroup ref="_slot.attlist"/>
</xs:complexType>
<xs:element name="_slot" type="_slot.type"/>

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

<!ENTITY % _slot.content "(ind | var)">

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

becomes

<xs:redefine schemaLocation="urcbindatagroundlog.xsd">
   <xs:group name="_slot.content">
      <xs:choice>
         <xs:group ref="_slot.content"/>
         <xs:element ref="var"/>
      </xs:choice>
   </xs:group>
</xs:redefine>

XSD Representation

An XML Schema representation of RuleML Version 0.85 has been created with a modularization and implementation approach that is consistent with the DTDs.

Future Work


Site Contact: Harold Boley. Page Version: 2004-01-28


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