W3C

RIF Combination with XML data

W3C Working Draft 11 May22 June 2010

This version:
http://www.w3.org/TR/2010/WD-rif-xml-data-20100511/http://www.w3.org/TR/2010/WD-rif-xml-data-20100622/
Latest version:
http://www.w3.org/TR/rif-xml-data/
Previous version:
http://www.w3.org/TR/2009/WD-rif-xml-data-20091001/http://www.w3.org/TR/2010/WD-rif-xml-data-20100511/ (color-coded diff)
Editors:
Christian de Sainte Marie, IBM

This document is also available in these non-normative formats: PDF version.

Copyright © 2010 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

Abstract

This document, developed by the Rule Interchange Format (RIF) Working Group, specifies how a RIF document can be combined with XML data documents.data.

Status of this Document

May Be Superseded

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is being published as one of a set of 1011 documents:

  1. RIF Overview
  2. RIF Core Dialect
  3. RIF Basic Logic Dialect
  4. RIF Production Rule Dialect
  5. RIF Framework for Logic Dialects
  6. RIF Datatypes and Built-Ins 1.0
  7. RIF RDF and OWL Compatibility
  8. OWL 2 RL in RIF
  9. RIF Combination with XML data (this document)
  10. RIF In RDF
  11. RIF Test Cases

XML Schema Datatypes Dependency

RIF is defined to use datatypes defined in the XML Schema Definition Language (XSD). As of this writing, the latest W3C Recommendation for XSD is version 1.0, with version 1.1 progressing toward Recommendation. RIF has been designed to take advantage of the new datatypes and clearer explanations available in XSD 1.1, but for now those advantages are being partially put on hold. Specifically, until XSD 1.1 becomes a W3C Recommendation, the elements of RIF which are based on it should be considered optional, as detailed in Datatypes and Builtins, section 2.3. Upon the publication of XSD 1.1 as a W3C Recommendation, those elements will cease to be optional and are to be considered required as otherwise specified.

We suggest that for now developers and users follow the XSD 1.1 Last Call Working Draft. Based on discussions between the Schema, RIF and OWL Working Groups, we do not expect any implementation changes will be necessary as XSD 1.1 advances to Recommendation.

Summary of Changes

There have been no substantive changes since the previous version . For details on the minor changes seeThe change log and color-coded diff .semantics were completely reworked.

Please Comment By 8 June20 July 2010

The Rule Interchange Format (RIF) Working Group seeks public feedback on this Working Draft. Please send your comments to public-rif-comments@w3.org (public archive). If possible, please offer specific changes to the text that would address your concern. You may also wish to check the Wiki Version of this document and see if the relevant text has already been updated.

No Endorsement

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Patents

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. The group does not expect this document to become a W3C Recommendation.W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

1 Overview

The Rule Interchange Format (RIF) is a format for interchanging rules over the Web. Rules that are exchanged using RIF may refer to external data sources and may be based on data models that are represented using a language different from RIF. This document specifies how acombinations of RIF document can be combineddocuments and XML data, possibly associated with XML schemas, are interpreted.

Extensible Markup Language (XML) is a simple, flexible text format derived from SGML (ISO 8879). Originally designed to meet the challenges of large-scale electronic publishing, XML is also playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere. The XML Schema Definition Language offers facilities for describing the structure and constraining the contents of XML documents. The schema language, which is itself represented in an XML vocabulary, provides a way to describe and to share the data model that is associated with the data in an XML document.

This document specifies a standard semantics for combinations of RIF documents and XML data. It definesuses a data model for XML instancedocuments, that is a simplified version of the XQuery 1.0 and XPath 2.0 Data Model [XDM ],].

The XQuery 1.0 and it specifies how the RIF condition language can be interpreted with respect to an XML document, and what is the associated semantics, in accordance with that data model. The XQuery 1.0 and XPath 2.0 Data Model (XDM)XPath 2.0 Data Model (XDM) specifies what information is accessible in a collection of XML documents, but it does not specify the language used to represent or access the data: this document specifies an implementation, using the RIF condition language, of a simplified version of the XDM. This makes the RIF condition language comparable to other implementations of the XDM, such as [XPath 2.0] and [XQuery 1.0].

Essentially, this document specifies: how XML documents, possibly associated with XML schemas, are imported in a RIF document; how sets of elements with given name or type properties, in an XML instance document, can be represented in RIF; and how the relation between parent elements and children elements and attributes, in an XML instance document, can be represented in RIF, when the children have given name and type properties.Like the XQuery 1.0 and XPath 2.0 Data Model, the simplified version used in this document supports the following classes of XML documents:

Accordingly, this document specifies how a RIF document is combined with well-formed XML documentswell-formed, and, where available, the correspondingan XML schemas, identified usingschema is specified, schema-valid XML documents. The rif:Import construct. Editor's Note: Itsemantics is intended that, in a future draft, an instanceindependent on the provenance of the XML data model can also be constructed from non-XML sources such as relational tablesin a database or object instances.combination: it can be imported explicitly in this case,a RIF document will be interpreted with respect todocument, or combined on the serializationconsumer-side, or a combination of the source according to anboth. However, only XML schemaschemas that MUST beare explicitly imported in the RIF document. An XML schema can also be combined with a RIFdocument without the associated data source being specified: in that case,are taken into account for the selectioninterpretation of the data source to be combined with the RIF document is left to the RIF document consumer.combination. This provides a way to communicate the data model that is intended, in a RIF document, for the data source, without specifying an actual data source.

Editor's Note: ThisSection will be completed, e.g. with typical usage scenarios, in a future draft.2 Importing XML documents and schemas in RIF In RIF,specifies how the Importrif:Import directive is used to communicate the location ofimport an externalXML document to be combined withand an XML schema are import in a RIF document.

The RIF document thatdata model for XML documents is described in section 3.

Section 4 specifies a standard semantics for RIF combinations with XML data: first, a model-theoretics semantics is given to RIF BLD combination with XML data, with and without associated XML schema (section 4.1); the operational semantics of RIF PRD combinations with XML data is, then, defined, based on the definition of a RIF BLD+XML data combined interpretation (section 4.2); finally, the semantics of RIF Core combinations with XML data is defined with respect to the model-theoretic semantics of the combination of RIF BLD and XML data and the operational semantics of the combination of RIF PRD and XML data (section 4.3).

Editor's Note: This section will be completed in a future draft.


2 Importing XML documents and schemas in RIF

In RIF, the Import directive is used to communicate the location of an external document to be combined with the RIF document that contains the directive and, optionally, a profile that governs the combination.

In [RIF-Core], [RIF-PRD] and [RIF-BLD], the use of the Import directive is limited to identifying an imported RIF document, or an RDF graph or an OWL ontology to be combined with a RIF document. An optional profile that governs the combination of a RIF document with an RDF graph or an OWL ontology can also be provided, as specified in [RIF-RDF-OWL].

This specification extends the Import directive in twofour ways:

  1. a newThe IRI of any XML document is allowed value andas a new setvalue of allowable values are specifiedthe location sub-element, that contains the IRI that identifies the imported data document;
  2. The new value: http://www.w3.org/2007/rif-import-profile#xml-data, is defined for the profile of an import, in addition to the values specified in [ RIF-RDF-OWL ]:indicating that the new valueimported document is the URI: http://www.w3.org/2007/rif-import-profile#xml-data ;an XML document with no associated XML schema;
  3. In addition, any URIIRI that identifies an XML schema document is allowed as a profile.profile, identifying the location sub-element,XML schema that containsis associated with the IRIimported XML data;
  4. Finally, a new value: http://www.w3.org/2007/rif-import-location#no-data, is allowed for the location of an import, indicating that identifiesthe importeddirective does not require the import of a data document, is made optional as well.document

Editor's Note: The extended syntax is still under discussion. Another approach would beOther approaches include: (i) to make the location sub-element optional as well; (ii) to reserve new keywords in the http://www.w3.org/2007/rif-import-profile namespace, such as: xml-schema, xml-schema-valid-data, etc, and to add a specific construct for the schema locator.

The BNF-style pseudo-schema for the modified syntax is as follows: <Import> <location> xs:anyURI </location>? <profile> xs:anyURI </profile>? </Import> Thefollowing constraints must be satisfied:

This specification does not prescribe the behaviour of a conformant implementation when one of the above constraintconstraints is not satisfied.

This specification does not prescribe the behaviour of a comformantconformant implementation when an Import directive contains a profile that is neither rif:xml-data ,nor an URIIRI that identifies an XML schema.

3 A simple data model for XML documentsExample 2.1. The data model described in this section specifiesfirst three import directives, below, are valid; the information thatfourth is accessible in an XML document, possiblynot:

  1. Import(http://example.org/customertable.xml http://www.w3.org/2007/rif-import-profile#xml-data)
  2. Import(http://example.org/customertable.xml http://example.org/customertable.xsd)
  3. Import(http://www.w3.org/2007/rif-import-location#no-data http://example.org/customertable.xsd)
  4. Import(http://www.w3.org/2007/rif-import-location#no-data http://www.w3.org/2007/rif-import-profile#xml-data)

The first directive says that the rules in combinationthe importing RIF document are to be combined with anthe data in the XML schema,document identified by the IRI: http://example.org/customertable.xml and that there is used to specifyno data model associated with the interpretationimported data in the form of an XML schema.

The second directive says that the rules in the importing RIF condition language with respectdocument are to an XML instance document.be combined with the data model is a stripped down version ofin the XQuery 1.0XML document identified by the IRI: http://example.org/customertable.xml and XPath 2.0that there is a data model [ XDM ]. As a consequence,associated with the RIF condition language can be considered a partial implementationimported data, in the form of the XQuery 1.0 and XPath 2.0 Data Model, andXML schema that is identified by the interpretation ofIRI: http://example.org/customertable.xsd.

The RIF condition languagethird directive says the data that is combined with respectthe rules is expected to XML documents canbe specified in termsan instance of the XQuerydata model that is imported as the XML schema identified by the IRI: http://example.org/customertable.xsd; but the directive does not say what data is to be combined with the rules.

The fourth directive violates one of the constraint: therefore, it is out of the scope of this specification.

Notice that none of the three valid directives is incompatible with the other two, but that combining the first two is confusing and error-prone, and should be avoided; and that the third one is redundant with the second, and that combining the two is useless and confusing, and that it should be avoided.

3 A simple data model for XML documents

This section defines the RIF data model for XML documents (henceforth "the data model"). The data model serves two purposes: it specifies the information that is accessible to a RIF consumer in an XML document, possibly in combination with an XML schema; and it is used to specify the interpretation of the combination of RIF with XML data.

The data model is a simplified version of the XQuery 1.0 and XPath 2.0 Data Model [XDM]. As a consequence, the RIF condition language can be considered a partial implementation of the XQuery 1.0 and XPath 2.0 Data Model, and the interpretation of the RIF condition language with respect to XML documents can be specified in terms of the XQuery 1.0 and XPath 2.0 Data Model or its implementations, such as XPath 2.0 [XPath 2.0]. This document will reuse definitions from the XQuery 1.0 and XPath 2.0 Data Model and the XPath 2.0 specifications, as appropriate, and otherwise provide pointers and examples where relevant.

3.1 Definitions

The data model specifies the information items from the XML infoset [Infoset] and from the post-schema validation infoset (PSVI), or derived from the infoset and the PSVI, that are required to interpret some RIF constructs with respect to an XML instancedocument.

Definition (Information item). (from [Infoset]) An information item is an abstract description of some part of an XML document: each information item has a set of associated named properties.  ☐

In this document, an information item is said to be constructed from an infoset, if the data item that it describes is contained in a data source that is not associated with an XML schema when it is imported in RIF. If the data source is associated with an XML schema, all the information items used to describe the content of that data source are said to be constructed from a PSVI.

If an information item is constructed from an infoset, all general and external parsed entities must be fully expanded before the data model is constructed.

In this specification, the property names are shown in square brackets, [thus].

The data model relies on three types of information items:

Given a data source, the relevant set of information items may be created by methods other than parsing and/or schema-validating an XML document. This specification does not describe or prescribe any method for retrieving the required information from a data source, possibly combined with an XML schema.

This specification distinguishes between the data model as a general concept and specific items (information items or atomic values) that are concrete examples of the data model. SomeFor the purpose of this specification, the term instance of the data model will be used exclusively to denote such concrete examples are being particularly distinguished by being identified as instancesof the data model .that are sequences of element information items in document order. Definition (Instance of the data model). An instance of the data model is a sequence of element information items, in document order. In particular, given an XML document D, the instance of the data model that describes D is the sequence of all the element information items that describe an element contained in D, in document order.  ☐

When there is no ambiguity with respect to D, the instance of the data model that describes D will be called, simply: the instance of the data model.

Definition (Atomic value). An atomic value is a value in the value space of an atomic type and is labeled with the name of that atomic type.  ☐

Definition (Atomic type). An atomic type is one of the 20 primitive simple types defined in Section 3.3 Primitive Datatypes of [XSD 1.1 Part 2] or a type derived by restriction from another atomic type.  ☐

Types derived by list or union are not atomic.

Definition (Sequence). A sequence is an ordered collection of zero or more information items.  ☐

A sequence cannot be a member of a sequence. An important characteristic of the data model is that there is no distinction between an item (a information item or an atomic value) and a singleton sequence containing that item. An item is equivalent to a singleton sequence containing that item and vice versa.

Except when specified otherwise, sequences are ordered according to the document order.

Definition (Document order). A document order is defined among all the element information items that describe a given XML instancedocument. Document order is a total ordering. Informally, document order is the order in which nodes appear in the XML serialization of a document.  ☐

Within a tree, document order satisfies the following constraints:

  1. The root node is the first node.
  2. Every node occurs before all of its children and descendants.
  3. The relative order of siblings is the order in which they occur in the children[children] property of their parent node.
  4. Children and descendants occur before following siblings.

XML element, attribute and type names are usually represented as XML qualified names, or QNames. However, xs:QName is not a RIF-Core built-in datatype. In the data model, all qualified names, including atomic values, are represented as expanded QNames.

Definition (Expanded QName). An expanded QName is a pairset of two values,three values consisting of a possibly empty prefix, a possibly empty namespace URIIRI and a local name.  ☐

3.2 ElementNotice that the prefix is never used in this document, and expanded QNames will be dealt with, in all but definition, as consisting of a possibly empty namespace IRI and a local name

3.2 Element information items

There is an element information item for each element appearing in the XML document. One of the element information items corresponds to the root of the element tree, and all other element information items are accessible by recursively following its [children] property.

An element information item has the following properties:

  1. [namespace name] The namespace name, if any, of the element type.element. If the element does not belong to a namespace, this property has no value.value;
  2. [local name] The local part of the element-typeelement name. This does not include any namespace prefix or following colon;
  3. [children] An ordered list of child information items, in document order. This list contains only element information items and character information items, one for each element and data character appearing immediately within the current element. It does not contain other kinds of information items, such as attribute information items, even if the XML element described by the information item has attributes. If the element is empty, this list has no members;
  4. [root] The element information item that describes the root element in the XML document. The [root] property of all the element information items that describe elements contained in the same XML instancedocument point to the same root element information item, including that root element information item itself. If the [root] property of an element information item points to that element information item itself, the [root] properties of all the element information items that are accessible by following its [children] property, recursively, must point to that same root element information item;
  5. [attributes] An unordered set of attribute information items, one for each of the attributes of this element. This includes all of the "special" attributes (xml:lang, xml:space, xsi:type, etc.) but does not include namespace declarations (because they are not attributes). Default and fixed attributes, e.g. provided by XML Schema processing, are added to the [attributes]. If the element has no attributes, this set has no members;
  6. [type name] The [type name] property of an element information item is empty if, and only if, the element information item is constructed from an infoset. If the element information item is constructed from a PSVI, the type name is represented by an expanded QName. It is determined as described in Section 3.3.1.1. Element and Attribute Node Type Names from [XDM] (reproduced in appendix 9.1, Element and attribute node type NAMEnames, for the reader's convenience);
  7. [string value] The normalised representation of the content of the element as a string. The string value is calculated as follows:
  8. [typed value] The typed-value is calculated as follows:
  9. [is-id] If the [type name] property of an element information item is empty, or if the element has a complex type with element-only content, the [is-id] property is false. Else, if the typed value of the element consists of exactly one atomic value, that value is of type xs:ID, or a type derived from xs:ID, the [is-id] property is true,true; otherwise it is false.false;
  10. [is-idrefs] If the [type name] property of an element information item is empty, or if the element has a complex type with element-only content, the [is-idrefs] property is false. Else, if any of the atomic values in the typed-value of the element is of type xs:IDREF or xs:IDREFS, or a type derived from one of those types, the [is-idrefs] property is true,true; otherwise it is false.

Editor's Note: Although minor, the deviations from the XQuery 1.0 and XPath 2.0 Data Model (XDM) may preclude using code developed for XDM. They are still under discussion. The working group is seeking feedback on the issue (ISSUE-103).

3.3 Attribute information items

There is an attribute information item for each attribute (specified or defaulted) of each element in the document, excluding those which are namespace declarations (because they are not attributes).

Attributes declared in the DTD with no default value and not specified in the element's start tag are not represented by attribute information items.

An attribute information item has the following properties:

  1. [namespace name] The namespace name, if any, of the attribute. Otherwise, this property has no value;
  2. [local name] The local part of the attribute name. This does not include any namespace prefix or following colon;
  3. [attribute type] An indication of the type declared for this attribute in the DTD. The only valuevalues that are relevant to this specification are ID, IDREF and IDREFS. If there is no declaration for the attributeattribute, or if no declaration has been read, this property has no value. The value of this property is not affected by the validity of the attribute value;
  4. [owner element] The element information item which contains this information item in its [attributes] property;
  5. [type name] Empty if the attribute information item is constructed from an infoset. If the attribute information item is constructed from a PSVI, the type name is represented as an expanded QName, and it is determined as described in Section 3.3.1.1. Element and Attribute Node Type Names from [XDM] (reproduced in Appendix B for the reader's convenience);
  6. [string value] The schema normalized value PSVI property if that exists; otherwise, the normalized attribute value according to Section 3.3.3 Attribute-Value Normalization in [XML]). Note that, if the attribute has a typed value, any valid lexical representation of the typed value can be used to determine the string value;
  7. [typed value] The typed-value is calculated as follows:
  8. [is-id] If the attribute is named xml:id and its [attribute type] property does not have the value ID and its [type name] property does not have the value xs:ID, then [xml:id] processing is performed. This will assure that the value does have the type ID or xs:ID (if the attribute information item is constructed from an infoset or from a PSVI, respectively) and that it is properly normalized. The [is-id] property is always true for attributes named xml:id. Else, if the [attribute type] property has the value ID, or if the type name is xs:ID or a type derived from xs:ID, the [is-id] property is true; otherwise, it is false. This specicification does not prescribe the behaviour of a RIF consumer application if an error is encountered during [xml:id] processing.
  9. [is-idrefs] True if the value of the [attribue[attribute type] property is IDREF or IDREFS, or if any of the atomic values in the typed-value of the attribute is of type xs:IDREF or xs:IDREFS, or a type derived from one of those types. Otherwise, false.

3.4 Character information items

There is a character information item for each data character that appears in the document, whether literally, as a character reference, or within a CDATA section.

Each character is a logically separate information item, but applications are free to chunk characters into larger groups as necessary or desirable.

A character information item has the following properties:

  1. [character code] The ISO 10646 character code (in the range 0 to #x10FFFF, though not every value in this range is a legal XML character code) of the character.
  2. [element content whitespace] A boolean indicating whether the character is white space appearing within element content (see [XML], Section 2.10. White Space Handling). Note that validating XML processors are required to provide this information. If there is no declaration for the containing element, or if there are multiple declarations, or if no declaration has been read, this property has no value for white space characters. It is always false for characters that are not white space.

3.5 Resolution of references

Definition (Reference information item). Given an information item, I, whose [is-id] is true, and given an atomic value, id, of type ID, IDREF, xs:ID, or xs:IDREF, that matches one of the atomic values in I' s [typed value] property, the reference information item identified by id is the element information item, R, such that

Note that the reference information item is always an element.

Where this specification states, with respect to a set of information items, that the references are resolved, the following processing is applied to every information item in the set whose [id-refs] property is true:

No property value is changed in any information item: the references are resolved only on a "need-to-resolve" basis, where the specification of RIF as an implementation of the data model requires them to be resolved.

This specification does not prescribe a behavior if an error is encountered during reference resolution processing (such as IDREFs without corresponding IDs, invalid or duplicate ID ,s, etc).

3.6 Example of a data model instance

Consider the following XML instancedocument, representing data about customers, that can be retrieved from the IRI: http://example.org/customertable/customers.xml :customers: 

<CustomerTable xmlns="http://example.org/customertable"
                xmlns:xml=" http://www.w3.org/XML/1998/namespace ">xmlns:xml="http://www.w3.org/XML/1998/namespace">
  <Customer xml:lang="en">
    <Name> John </Name>
    <Account> 111 </Account>
  </Customer>
  <Customer xml:lang="fr">
    <Name> Jane </Name>
    <Account> 222 </Account>
     <Id><PIN> 222  </Id></PIN>
  </Customer>
</CustomerTable>

Consider, further, the following XML schema, available from http://example.org/customertable/customers.xsd :schema: 

<xs:schema  xmlns:xs=" http://www.w3.org/2001/XMLSchema " xmlns:xml=" http://www.w3.org/XML/1998/namespace " targetNamespace="http://example.org/customertable">xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:xml="http://www.w3.org/XML/1998/namespace"
           targetNamespace="<nowiki>http://example.org/customertable</nowiki>"
           xmlns="<nowiki>http://example.org/customertable</nowiki>">  

  <xs:simpleType name="PIN">
    <xs:restriction base="xs:integer">
      <xs:minInclusive value="100"/>
      <xs:maxExclusive value="1000"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:element name="Name" type="xs:string"/>
  <xs:element name="Account" type="xs:integer"/>
  <xs:element  name="Id" type="xs:integer"/>name="PIN" type="PIN"/>
  
  <xs:element name="Customer">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="Name"/>
        <xs:element ref="Account"/>
        <xs:element  ref="Id"ref="PIN" minOccurs="0"/>
      </xs:sequence>
    </xs:complexType>
    <xs:attribute ref="xml:lang"/>
  </xs:element>

  <xs:element name="CustomerTable">
    <xs:complexType>
      <xs:all>
        <xs:element ref="Customer" minOccurs="0"/>
      </xs:all>
    </xs:complexType>
  </xs:element>

</xs:schema>

The instance of the data model that describes the XML document associated with the schema,schema is a sequence that contains the following eight element information items, in that order:the same order as the numbered list below. When relevant to examples further in this document, the values for some of the properties are given for both cases where the instance of the data model had been constructed from the infoset, marked as: (no schema), and where it has been been constructed from the PSVI, marked as: (schema):

  1. an element information item representing the CustomerTable element, with the following values for its properties
  2. an element information item that describes the first Customer element in the document, with the following values for its properties
  3. an element information item representing the Name sub-element of the first Customer element in the document, with the following values for its properties
  4. an element information item representing the Account sub-element of the first Customer element in the document, with the following values for its properties
  5. an element information item that describes the second Customer element in the document;
  6. an element information item representing the Name sub-element of the second Customer element in the document;
  7. an element information item representing the Account sub-element of the second Customer element in the document;
  8. an element information item representing the IdPIN sub-element of the second Customer element in the document;document, with the following values for its properties


4 RIF combination with XML documentsdata

This section specifies, for some constructsspecifies the semantics of the combination of RIF condition language, an interpretationdocuments and XML data, for RIF Core, RIF PRD and RIF BLD, where the XML data may be associated with respect toan XML schema.

Definition (RIF+XML data combination). A RIF+XML data combination is a tuple <R, D1, ..., Dn>, n ≥ 1, where R is a RIF document and D1, ..., Dn are XML documents.   ☐

One use case for the instancescombination of the aboveRIF and XML data model that representis when a RIF document imports explicitly the importeddata sources.to which the specification provides, therefore, a meansrules are to combinebe applied: this is the case when the RIF documents with XML documents, withdocument contains one or withoutmore Import directives where the location identifies explicitly an associatedXML schema, as well as a mechanismdocument to associatebe combined with athe importing RIF document. In that case, the combination is imposed by the producer of the RIF document, as well as the data modelto be combined with the rules that is assumed, inthe interchanged rules, forRIF document contains. We call that case: producer-side combination, and the XML data sources, in the form of an XML schema (or a set of XML schemas). Editor's Note: This draft suggests thatto be combined with the RIF document: imported XML data.

However, a significant use case for RIF is importedrules being published or shared as a RIF facts, but it does not specify precisely how RIF data types, constants, lists and individuals relatedocument for consumers to type names and atomic types, typed values, sequences and information itemsapply them to their own data. In that case, the data model, respectively; nor does it specify precisely howconsumer of a RIF variable can be bound to, or interpreted with respectdocument decides independently of the producer to an information item, beyond requiring thatcombine the information itemsrules contained in an imported data model instance be part ofthe domain of interpretationRIF document with the data of his choice. We refer to that case as: consumer-side combination, and to the variable ( Section 4.2. Variables ).data that is combined with a RIF document as: consumer-side data.

This wholesection will be reworked, in a future draft, to providespecifies a propernormative semantics for the combination of a RIF documentsdocument with XML data, without distinguishing between the two cases; that is, independently of whether the XML data (a model-theoretic semantics for combinations involving RIF-Core and RIF-BLD documents, and an operational semantics for combinations involving RIF-Core and RIF-PRD documents). 4.1 Constants Any constant in a RIF document canto be interpretedcombined with respect to atomic values in a data model instance. Somethe RIF constant, those withdocument is imported XML data or consumer-side XML data, or a DM-Name , can alsocombination of both. However, it provides a means to require that consumer-side XML data be interpretedvalid with respect to the expanded QNamesan XML schema that represent element, attribute and type names in a data model instance. 4.1.1 DM-Namesis imposed by the producer of the RIF document.

Editor's Note: ...and thus to interchange, along with the rules, the data model relies on expanded-QNameswith respect to represent qualified names. However, RIF-Core has no built-in datatype for qualified names. In orderwhich they have been designed. And thus, to specify the interpretation ofcombine RIF constructswith respect toany data model instancesthat describe imported data sources, we define a mapping, DM-Names , from xs:string constants to expanded QNames, and wecan be represented in an XML Schema (including object models). Explanation, use that mapping to define the DM-Name of constants. Definition (DM-Names). DM-Names iscase and example will be added in a mapping from xs:string constants to expanded QNames .future draft.

Definition (Associated XML schema). An xs:string constant of the form [URI '#']? NAMEXML document, Di, is mapped toassociated with an expanded QName where the optional URI is the, possibly empty, namespace URI and NAME isXML schema, XSD, in the local name,context of a RIF+XML data combination, <R, D1, ..., Di, ..., Dn>, n ≥ 1, if and only if one of the substring URI , if present,following is true:

☐


4.1 Model-theoretic semantics of RIF constants that cannot be cast into an xs:string for whichBLD+XML data combinations

The DM-Names mapping is defined do not havemodel-theoretic semantics of RIF BLD defines a DM-Name.  ☐ By extension, givensemantic structure as a constant,tuple I = <TV, DTS, D, Dind, Dfunc, IC for which a DM-Name is defined, we will write, IV, IF, INF, Ilist, Itail, Iframe, Isub, Iisa, I=, Iexternal, Itruth>.

The namespace URIspecification of c andthe local namemodel-theoretic semantics of c to refer toa RIF BLD+XML data combination follows closely the namespace URI and local name componentsspecification of c' s DM-Name, respectively. Editor's Note:the definitionsemantics of DM-Name is still under discussion. It would be preferable if only rif:iri constants had DM-Names, but that would exclude element and attribute names that are not in a namespace (sincea rif:iri must be an absolute IRI). An related issueRIF BLD document, except that the notion of semantic structures is whether it would be useful to be able to relate an element/attribute namereplaced by the notion of RIF BLD+XML data combined interpretations: informally, RIF BLD+XML data combined interpretations are RIF BLD semantic structures, with an imported document, and how. Example 4.1.additional conditions on some of the DM-Nameelements of I.

The rif:iri constant <http://example.org/customertable#Customer>basic idea is an expanded QName wherethat pieces of imported data are represented, for the namespace URI is http://example.org/customertable andpurpose of combination with RIF, by information items in instances of the local name is Customer ;data model. Assertions about the DM-Namenames of XML elements in the xs:string constant <myElement> is an expanded QNameimported data, and, where the namespace URI is emptydefined, their types, are represented using class membership and subclass formulas, in the local name is myElement ;importing RIF documents. This document specifies a subset of the namespace URIlexical spaces of the symbol spaces rif:iri constant <http://www.w3.org/2001/XMLSchema#type(date)> is http://www.w3.org/2001/XMLSchema ,and its local name is type(date) ; The namespace URI of the xs:string constant <attribute(myAttribute)> is empty,xs:NCName and its local name is attribute(myAttribute) ; The DM-Namerequires that constants whose literals are in that subset be interpreted as classes of element information items, associated to XML element names and types.

In the xs:string constant "http://example.org/customertable#Customer" is an expanded QName wheresame way, assertions about the namespace URI is http://example.org/customertablevalues of attributes and sub-elements of XML elements, in the local name is Customer ; The rif:iri constant <http://example.org/> has no DM-Name.   ☐ 4.1.2 Class names Constants that occurimported data, are represented using frame formulas, in the importing RIF documents. This document specifies a position wheresubset of the identifierlexical spaces of a class is expected, e.g. in RIF class membershipthe symbol spaces rif:iri and subclass relationship formulas, canxs:NCName and requires that constants whose literals are in that subset be interpreted as identifying subsets[attribute] and [children] properties of theelement information itemsitems.

Example 4.1. In the instances of the data model that describe the imported data sources. Givena constant, C , for whichRIF document that imports the DM-Name is defined, and an instancesample XML document from Section 3.6. Example of thea data model instance, I DM , let us call: C-set ,associated with the setcorresponding XML schema, the first rule, below, says that containsan element information item, N ∈ I DM , if and onlyEarlyCustomer is a Customer whose Account number is lower than 1000: 

Forall ?x (_EarlyCustomer(?x) :-
           And( ?x # <http://example.org/customertable#Customer>
                Exists ?y (And ?x[<http://example.org/customertable#Account -> ?y]
                               External(pred:numeric-less-or-equal(?y 1000)))))

Notice that, if the local name in C 's DM-Name hasXML document were imported without the form type(NAME) , and, eitherXML schema, the namespace URI and NAME inRIF consumer processing the combination would only have access to the DM-Namestring value of C matchesthe namespace URI and local nameAccount sub-element, without an indication of its type. In N' s [type name] property, respectively; or the type identified by the namespace URI and local name in N 's [type name] property is derived by restriction from the type identified by the namespace URI and NAME in C 's DM-Name; or the namespace URI andthat case, to guarantee that the local name inrule behave as expected, the DM-Nameproducer of C matchthe [namespace name] andRIF document would have to add the [local name] propertiesinformation that the value of N , respectively; or N has been constructed from?y must be cast into an integer before being compared as a PSVI, andnumber.

Another example, below, shows a rule that involves a combination with data that is represented as an attribute in the elementXML document.: 

Forall ?x (_EnglishRec(?x) :-
           ?x[<http://www.w3.org/XML/1998/namespace#attribute(lang)> -> "en"^^xs:language])

That it describes belongsrule could be intended to a substitution group, occursmean that, if an item is represented, in a position wherethe schema requiresimported XML data, by an element with an attribute named lang in the head element,XML namespace, and the head element's namespace URI and local name matchvalue of that attribute is the namespace URI andxs:language constant en, then the local nameinformation regarding that item is recorded in english.


☐

As in the DM-Name of C , respectively. Thisspecification does not prescribe anything with respect toof RIF BLD, Const denotes the set of all constant symbols and Var denotes the set of all variable symbols.

4.1.1 Combined interpretation as class identifiers,of constants for whichRIF BLD non-document formulas and schemaless XML data

The DM-Namesimplest case is not defined. Givenwhen a RIF BLD document is combined with XML data, without an associated XML document, D ,schema: in that case, the setsinstance of element information items selected by a constant C fromthe data model instancethat describes D correspondsthe XML data is built from the infoset, and it does not assign a type to the sequences ofelements selected,and attributes contained in D , bythe following XPath 2.0 expressions, where prefix is boundXML document.

To URI : /descendant::element(*, [prefix:]NAME ) ifmake the definition simpler, we will write that:

Example 4.2.

Definition (RIF BLD+schemaless XML schema being associated to thedata combined interpretation). A RIF BLD+schemaless XML document, in the first example, above, the C-set would be empty: the information aboutdata combined interpretation is a element's type comes from the schema, and the [type name] properties would be empty for all thepair ({IDM}, I), where {IDM} is a set of element information items inconstructed from an infoset and where the data model instance; in the second example, the C-set would be unchanged, because the [namespace name]references have been resolved, and [local name] properties of an element information item depend on the XML instance element that it describes, only. ☐ 4.1.3 Slot names Constants that occur in a position where a slot's nameI is expected, e.g. in RIF frame formulas, can be interpreteda semantic structure, as identifying subsets of an element information item's [children] or [attributes] properties,defined in the instancessemantics of the data modelRIF BLD, that describesatisfies the imported data sources. Given afollowing additional conditions:

  1. {IDM} ⊆ DInd;
  2. For all frame formulas o [ slot -> vslot -> v ], where I(o identifies an element information item in a data model instance, and where slot is a RIF constant for which the DM-Name is defined, let us call: o/slot -sequence) = e ∈ {IDM}, the sequence constructed as follows, after references have been resolved :Itruth(I(>o [ slot -> v ])) = t (true) if one of the localfollowing is true:
    1. I(slot) = I("NAMESPACE#attribute(NAME in)"^^rif:iri), or I(slot 's DM-Name has the form attribute(NAME) , the o/slot -sequence) = I("attribute(NAME)"^^xs:NCName) and NAMESPACE is the, possiblyempty, subset ofwhere NAMESPACE and NAME are, respectively, the [attributes] propertyvalues of the element information item identified by o , that contains only the attribute information items whose[namespace name] property matches the namespace URI of slot 's DM-Name,and whose[local name] property matches NAME ; else, the o/slot -sequence is the possibly empty sub-sequence, in document order,properties of an attribute information item, a, in the [children][attributes] property of the element information item identified by oe, that contains only element information items whose [namespace name] property match the namespace URI in slot 's DM-Name,and whose [local name] property matches eitherv string-matches the local name in slot 's DM-Name,[string value] of a;
    2. or I(slot) = I("NAMESPACE#NAME , if the local name in"^^rif:iri), or I(slot 's DM-Name) = I("NAME"^^xs:NCName) and NAMESPACE is empty, where NAMESPACE and NAME are, respectively, the values of form list(NAME) ;the[namespace name] and [local name] properties of an element information items constructed from a PSVI, and such that the element that they represent belongs to a substitution group, occuritem, c, in a position where the schema requires the head element, and the head element's namespace URI matchesthe namespace URI in slot 's DM-Name[children] property of e, and its name matcheseither
      • the local name in slot 's DM-Name,[typed value] of c is c itself and I(v) = c;
      • or NAMEthe [typed value] of c is not c, ifand v string-matches the local[string value] of c;
    3. or I(slot) = I("NAMESPACE#list(NAME in)"^^rif:iri), or I(slot 's DM-Name) = I("list(NAME)"^^xs:NCName) and NAMESPACE is of form list(NAME) . Editor's Note: Shall we add a property that containsempty, where NAMESPACE and NAME are, respectively, the expanded QNames[namespace name] and [local name] of the relevant substitution groups' heads in theat least one element information item partin the [children] property of e, and v is a RIF List, and v has the data model? This specification does not prescribe anything with respect tosame length as the interpretationsub-list, c, of slot names for whichthe DM-Name is not defined. Given a XML instance element,[children] of e, that contains only the element information item that describes it in a data model instance, e ,items whose [namespace name] and a constant, C[local name] property match, respectively, NAMESPACE and NAME, in document order, and for which the DM-Name is defined, the sequenceeach pair of elements of information items selected from e by a constant C , that is,the e/C-sequence as defined above, corresponds,same rank, vi in v and ci in c,
      • either the absence of references, to the sequences[typed value] of nodes selected by the following XPath 2.0 expressions, where prefix , if present,ci is bound to URI ,ci itself and whereI(vi) = ci;
      • or the context element[typed value] of ci is E : attribute:: [prefix:]NAMEnot ci, if the, optional, namespace URI in C' s DM-Name is URIand if the local name hasvi string-matches the form attribute(NAME)[string value] of ci;
  3. child:: [prefix:]NAME (and child::schema-element( [prefix:]NAME )For all class membership formulas o # C, if the data model instance that containswhere I(o) = e is constructed from a PSVI),∈ {IDM}, Itruth(o # C) = t (true) if
    1. the, optional,I(C) = I("NAMESPACE URI in C' s DM-Name is URI and if the local#NAME"^^rif:iri), or I(C) = I("NAME"^^xs:NCName) and NAMESPACE is empty, where NAMESPACE and NAME are, respectively, the values of the [namespace name] and [local name] properties of e.

Example 4.3.  ☐

Notice that xs:NCName constants are included in the context ofdefinition to allow the interpretation of RIF+XML data model instance that describescombinations where some or all elements or attributes in the XML document from Section 3.6. Example of adata model instance , above, considerare not in a RIF frame expression ofnamespace. As defined in [RIF-DTB], the form o[slot->v] : iflexical space of rif:iri consists of all absolute IRIs as specified in [RFC-3987]; as a consequence, it does not allow the object, orepresentations of local names without namespaces.

Editor's Note: The definition will be further commented and explained in a future draft.

The truth valuation of a well-formed RIF BLD formula, φ, under a RIF BLD+schemaless XML data combined interpretation ({IDM}, I) is determined by Itruth exactly as specified for the element information item that describesinterpretation of RIF BLD non-document formulas (but with the root CustomerTable element, and if slot stands fordefinition of Itruth as modified by the rif:iri constant: <http://example.org/customertable#Customer>combination with XML data).

Example 4.3. With respect to a RIF BLD+XML data combination, <D, IDM>, where a RIF BLD document, D, imports the o/slot -sequence contains two ordered items, items 2 and 5 in thesample XML document from Section 3.6. Example of a data model instance as described in Section 3.6, that is, in document order:above, without associating it with any XML schema, and under the element information item that describessemantics for RIF BLD+schemaless XML data combinations as specified above, the first Customer elementfollowing facts must be true in all the document;interpretations where the element information itemspecified conditions hold: that describes the second Customer element; if o standsis, for each fact, f, Itruth(f) = t in all interpretations, I, where the second onespecified conditions hold. The facts may be true in other interpretations as well, but not as a consequence of these two element information items (the one aboutthe Customer element that describescombination (NB: the customer named "Jane"),examples use RIF non-normative presentation syntax, and, in particular, the shortcut presentation syntax for RIF constants, as described in RIF Data Types and if slot standsBuiltins, Section 2.2.2. Shortcuts for constants in RIF's presentation syntax; see Appendix D: Examples using the xs:string constant: "http://example.org/customertable#Name" ,RIF/XML normative syntax):

Notice that, if our example XML data sources as RIF facts in D , as specified (non-normatively)was not in a namespace, the Appendix C: Embedding importedsemantics of RIF+XML data sources as RIFcombinations would require that the following facts . 4.3 Class membership: rif:Member A class membership atom, obe true, all other required conditions being satisfied:

Example 4.4. Continuing withConsider the example XML instance document from Section 3.6 ,following element with mixed-content, and assume that the element is contained in a data model instance that describes it, and assumingsource that the following RIF class membership atoms occuris imported in a RIF document that imports the XMLdocument, without a namespace nor an associated with theXML schema fromschema: 

<letterBody>
  Thank you for ordering the  example: ?customer#"http://example.org/customertable#Customer" is<item>widget</item>.
  It should arrive by <arrivalDate>09-09-09</arrivalDate>
</letterBody>

Itruth must, under the semantics specified above, map the fact:
_myLetter["letterBody" -> "Thank you for ordering the Widget. It should arrive by 09-09-09"],
to true ifin any interpretation of the variable ?customer is boundRIF+XML data combination that maps the RIF local constant _myLetter to an element information item that describes one of the two Customer elementsdescribes, in the importeddata model instance, the parent element of the above letterBody element.

4.1.2 Combined interpretation of RIF BLD non-document formulas and schema valid XML document; 111#<http://www.w3.org/2001/XMLSchema#type(integer)> is always false, as far as this specification is concerned: indeed,data

In the atom does not test whether 111case where a RIF BLD document is an integer, but whether 111 identifies an element information itemcombined with XML data that describesis associated with an elementXML schema, the instance of type xs:integer inthe data model instancethat describes anthe imported XML data source. ☐ 4.4 Sub-class relationship: rif:Subclass A sub-class relationship atom, s ## C , where s and C stand for RIF constants whose DM-Name are defined,is true if,built from the s -set isPSVI, and it does ascribe a subsettype to the elements and attributes contained in the XML document.

The semantics of these combinations are, essentally, the same as in the schemaless case, except that values are compared using their typed values instead of their string values, and additional conditions are imposed on Itruth to take into account information that is specific to the PSVI.

Accordingly, and to make the definition simpler, we will write that:

In addition we will write, in the following definition, that two strings, a namespace and an NCName, match, possibly modulo a substitution, the values of, respectively, the [namespace name] and [local name] of an element information item, e, if

This specification does not prescribe any semantics for a RIF+XML data combination, when the XML data is associated with an XML schema with respect to which it is not valid.

Definition (RIF BLD+schema valid XML data combined interpretation). A RIF BLD+schema valid XML data combined interpretation is a pair ({IDM}, I), where {IDM} is a set of element information items constructed from one or more PSVIs, using one or more XML schemas, XSDi, and where the references have been resolved, and I is a semantic structure, as defined in the semantics of RIF BLD, that satisfies the following additional conditions:

  1. {IDM} ⊆ DInd;
  2. For all frame formulas o [ slot -> v ], where I(o) = e ∈ {IDM}, Itruth(o [ slot -> v ]) = t (true) if one of the following is true:
    1. I(slot) = I("NAMESPACE#attribute(NAME)"^^rif:iri), or I(slot) = I("attribute(NAME)"^^xs:NCName) and NAMESPACE is empty, where NAMESPACE and NAME are, respectively, the values of the [namespace name] and [local name] properties of an attribute information item, a, in the [attributes] property of e, and v type-matches the [typed value] of a;
    2. or I(slot) = I("NAMESPACE#NAME"^^rif:iri), or I(slot) = I("NAME"^^xs:NCName) and NAMESPACE is empty, where NAMESPACE and NAME match, possibly modulo a substitution, the values of, respectively, the [namespace name] and [local name] properties of an element information item, c, in the [children] property of e, and either
      • the [typed value] of c is c itself and I(v) = c;
      • or the [typed value] of c is not c, and v type-matches the [typed value] of c;
    3. or I(slot) = I("NAMESPACE#list(NAME)"^^rif:iri), or I(slot) = I("list(NAME)"^^xs:NCName) and NAMESPACE is empty, where NAMESPACE and NAME match, possibly modulo a substitution, the values of, respectively, the [namespace name] and [local name] properties of at least one element information item in the [children] property of e, and v is a RIF List, and v has the same length as the sub-list, c, of the [children] of e, that contains only the element information items whose [namespace name] and [local name] properties are matched, possibly modulo a substitution, by, respectively, NAMESPACE and NAME, in document order, and for each pair of elements of the same rank, vi in v and ci in c,
      • either the [typed value] of ci is ci itself and I(vi) = ci;
      • or the [typed value] of ci is not ci, and vi type-matches the [typed value] of ci;
  3. For all class membership formulas o # C, where I(o) = e ∈ {IDM}, Itruth(o # C) = t (true) if one of the following is true
    1. I(C) = I("NAMESPACE#NAME"^^rif:iri), or I(C) = I("NAME"^^xs:NCName) and NAMESPACE is empty, where NAMESPACE and NAME are the values, respectively, of the [namespace name] and the [local name] properties of e;
    2. or I(C) = I("NAMESPACE#type(NAME)"^^rif:iri), or I(C) = I("type(NAME)"^^xs:NCName) and NAMESPACE is empty, where NAMESPACE and NAME are, respectively, the namespace and the local name in e 's [type name] property;
  4. DTS is extended to include all the simple types, whether built-in XML schema or defined in one of the XSDi, that are mentioned in the [type name] property of any of the information items in the data model instance.
  5. For all subclass formulas sub ## SUP, where sub and SUP are distinct constants of type rif:iri or xs:string, or a type derived from rif:iri or xs:string, Itruth(sub ## SUP) = t (true) if one of the following is true:
    1. I(sub) = I("NAMESPACEsub#type(NAMEsub)"^^rif:iri), or I(C) = I("type(NAMEsub)"^^xs:NCName) and NAMESPACEsub is empty, where NAMESPACEsub and NAMEsub are, respectively, the values of the target namespace and name of an element, esub defined in XSD, one of the XSDi and
      • either I(SUP) = I("NAMESPACESUP#NAMESUP"^^rif:iri), or I(C) = I("NAMESUP"^^xs:NCName) and NAMESPACESUP is empty, where NAMESPACESUP and NAMESUP are, respectively, the values of the target namespace and name of an element, eSUP defined in XSD, and esub is defined in a substitution group where the head element is eSUP;
      • or I(SUP) = I("NAMESPACESUP#type(NAMESUP)"^^rif:iri), or I(C) = I("type(NAMESUP)"^^xs:NCName) and NAMESPACESUP is empty, where NAMESPACESUP and NAMESUP are, respectively, the values of the target namespace and name of an XML schema type, TSUP, defined in XSD (not including built-in XML schema data types), and TSUP is the type declared in the definition of esub, in XSD;
    2. or I(sub) = I("NAMESPACEsub#type(NAMEsub)"^^rif:iri), or I(C) = I("type(NAMEsub)"^^xs:NCName) and NAMESPACEsub is empty, and I(SUP) = I("NAMESPACESUP#type(NAMESUP)"^^rif:iri), or I(C) = I("type(NAMESUP)"^^xs:NCName) and NAMESPACESUP is empty, where NAMESPACEsub and NAMEsub are, respectively, the values of the target namespace and name of and XML schema type, Tsub, defined in XSD (not including built-in XML schema data types), and NAMESPACESUP and NAMESUP are, respectively, the values of the target namespace and name of an XML schema from the example. It is false in the schema-less case introduced in example 4.2type, TSUP, however, since, in that case, the super-class is always empty: <Subclass> <sub> <Const type=" xs:string ">http://example.org/customertable#Account</Const> </sub> <super> <Const type=" rif:iri ">http://www.w3.org/2001/XMLSchema#type(integer)</Const> </super> </Subclass> The subclass relationship atom that is represented below in RIF-PRD/XML (ordefined in RIF-BLD/XML) is false, as far as this specification is concerned, if theXSD (not including built-in XML schema data model instancetypes), and Tsub is constructedderived by restriction or by extension from TSUP.

  ☐

Editor's Note: The PSVI. However, it is true if the data model instance has been constructed fromcase defined by the infoset (and no other data source is imported), although an xs:integer element can neverfirst bullet under 2.b and 2.c could be further refined, to differentiate between the case of an xs:stringempty element as well: that is because both classes are empty, in that case. Indeed, the subclass relationship tests thatand the setcase of the xs:integer elementsnull value: in the imported data sources is contained inlatter case, the set ofschema must define a nillable content for the xs:string elementselement. Shall we leave the interpretation to the implementations or shall we include it in that spec? If the same imported data sources; not whether xs:integer is a subtype of xs:string : <Subclass> <sub> <Const type="xs:string">http://www.w3.org/2001/XMLSchema#type(integer)</Const> </sub> <super> <Const type="rif:iri">http://www.w3.org/2001/XMLSchema#type(string)</Const> </super> </Subclass> ☐ 4.5 Frames: rif:Framelatter, we must include a frame o [ slot -> v ] , where o identifies an element information itemrif:NULL constant in an importedevery symbol space...

Editor's Note: Condition 4 will be further refined in a future draft, to account for the problem posed by the inclusion of some data model instance, and where v identifiestypes in a constant whose DM-Name is defined, is true either ifRIF interpretation, e.g. xs:duration.

Editor's Note: The local namedefinition will be further refined in slot DM-Name hasa future draft to account for cases such as xs:anyType typed elements.

Editor's Note: The form list(NAME)definition will be further commented and v isexplained in a future draft.

The truth valuation of a well-formed RIF list that containsBLD formula, φ, under a RIF BLD+schema valid XML data combined interpretation ({IDM}, I) is determined by Itruth exactly as specified for the typed valueinterpretation of allRIF BLD non-document formulas (but with the information items indefinition of Itruth as modified by the o/slot -sequencecombination with XML data).

Example 4.5. Following up on Example 4.3, inabove, but assuming that the RIF BLD document order; or if v matchesis combined with the [typed value] property of, at least, one ofsample XML data, associated with the information itemsXML schema, as in the o/slot -sequence .Section 3.6. Example 4.6. Continuingof a data model instance, the following hold with respect to the previous example :interpretation of sample facts, under the frame ?x[<http://example.org/customertable#Customer> -> ?y] issemantics of the RIF BLD+schema valid XML data combination:

Notice that describes it points, therefore,_PIN_Jane # <http://www.w3.org/2001/XMLSchema#type(integer)> is never required to the information item itself. For the same reason (element-only children), the valuebe true in any interpretation of the frame is the sameexample RIF BLD+schema valid XML data combination, even in interpretations where IC maps _PIN_Jane on the schema-less case, introducedlast element in example 4.2 ; The frame ?x[<http://example.org/customertable#list(Customer)> -> ?y] is true, for the same binding of ?xIDM, if ?y is bound to the sequence that contains, in document order,although the two element information itemsXML schema type http://example.org/customertable#PIN is derived by restriction from xs:integer. That describe the two Customer sub-elements,is because xs:insteger is not defined in the data model instance; The frame ?y[<http://example.org/customertable#Account> -> 111] is true ifassociated XML schema ("the namespace of C and only if ?y is bound toNAME [must] match, respectively, the element information item that representstarget namespace and the Customer element withname "John",of an XML schema type defined in the importedXSD (not including built-in XML schema data source. This holdstypes)", condition 4.b in the schema-less case as well;definition of RIF BLD+schema valid XML data combined interpretations).

4.1.3 Combined interpretation of RIF BLD documents and XML data

Editor's Note: The typed-value, indefinition of the schema-less case,combined interpretation of non-document RIF BLD formulas and XML data, where some of the XML data is associated with an XML schema and some is not, follows directly from the string-value, that is,definitions of the schemaless and schema valid cases. It will be developed explicitly in a string. So,future draft.

A RIF+XML data combination <R, D1, ..., Dn>, n ≥ 0, where R is an RIF BLD document, and the xs:integer 111Di, 1 ≤ i ≤ n, are all the XML documents that are, either, imported, directly or indirectly, by R, or that contain consumer-side XML data, is not equal tointerpreted using a RIF BLD+XML data combined interpretation ({IDM}, Î), where:

The string-valuetruth valuation of the Account element would be known, not its type; The frame ?y[<http://www.w3.org/XML/1998/namespace#attribute(lang)> -> "en"^^xs:language] is true, in the example, if ?ya RIF+XML data combination <R, D1, ..., Dn>, n ≥ 0, is bound todetermined exactly as specified for the element information item that representstruth valuation of a RIF BLD document formulas, using the Customer element with Name "John",RIF BLD+XML data combined interpretation ({IDM}, Î) in the imported XML document. This holdsplace of a semantic multi-structure.

In the schema-less case as well.  ☐ Example 4.7. Considersame way, the following element withnotions of model and of logical entailment are defined for a mixed-content: <letterBody> Thank youRIF BLD+XML data combined interpretation, using exactly the same definition as specified for orderingRIF BOLD (document and non-document) formulas, where the <item>widget</item>. It should arrivesemantic multi-structure, Î, is replaced by <arrivalDate>09-09-09</arrivalDate> </letterBody> Assume thatthe element is containedRIF BLD+XML data combined interpretation ({IDM}, Î).

Notice that, in athe case where no XML data sourceis imported, that is, if n = 0, {IDM} is imported in a RIF document,empty, and assume thatthe interpretation of a RIF variable ?v , occurring in thatBLD document under a RIF document,BLD+XML data combined interpretation (∅, Î) is boundstrictly equivalent to an element information item that describes, inits interpretation under the standard RIF BLD semantics.

4.2 Operational semantics of RIF PRD+XML data model instance,combinations

The parent elementeffect of the above letterBody element.combination with XML data, with or without an associated XML schema, on the valueoperational semantics of the frame ?x["letterBody"->?y] will be true is and only if ?y is bound toa string constantRIF PRD document, is that contains the following text: "Thank you for orderinga ground fact, f, must be added to the Widget. It should arrive by 09-09-09" ;set of ground facts that is,is associated with the string valuestate of the information itemfact base that describesis to be combined with the letterBody element. Indeed,XML data, if an element has a complex type with mixed content (including xs:anyType ), its typed valueit is its string value.   ☐ 4.6 Atoms: rif:Atom An atom, P(a 1 ... n ) , n ≥ 0 , where P stands fortrue under a RIF constant whose DM-Name is defined, is true if there is, at least, one element information item, e ,BLD+XML data combined interpretation, as defined in the P -set constructed from the union ofprevious section (schemaless or schema valid case, depending on whether the importedXML data model instances, such that the [typed value] property of e points to e itself; and nis associated with an associated schema or not).

See also the number of items in the [children] property of e ; and the a i match, respectively, the [typed value] properties of each(non-normative) appendix on embedding XML data as RIF facts for an exhaustive description of the element information items infacts to be added to the [children] propertyinitial state of e , in document order, afterthe references have been resolved . Editor's Note: Isfact base that one useful? If we decideis to keep it, it needs some more work. E.g., dealing with missing children elements (when minOccur = 0); dealingbe combined with the fact that P can occur both inXML data.

Editor's Note: The position of a class identifierdefinition will be further commented and explained in a membership or subclass relationship formula, or as the name of a relationfuture draft.

Example.

Editor's Note: Examples will be added in an atom; etc. A atom with named arguments, P((name 1 a 1 ) ... (name n n )) , n ≥ 0 , where P stands fora future draft.

4.3 Semantics of RIF constant whose DM-NameCore+XML data combinations

RIF Core is defined and eacha syntactic subset of RIF BLD, and the name i aresemantics of RIF names whose DM-Name is defined,Core+XML data combinations is true if there is, at least, one element information item, e , inidentical to the P -set , suchsemantics of RIF BLD+XML data combinations for that the [typed value] propertysubset. RIF Core is also a syntactic subset of e points to e itself;RIF PRD, and each a i matchesthe sequencesemantics of RIF Core+XML data combinations is also identical to the typed values of eachsemantics of the information items in the e/ name i -sequence ,RIF PRD+XML data combinations for that subset.

Notice, in document order. Noteparticular, that the ordercondition on the interpretation of subclass formulas, condition 5 in whichthe (name idefinition of a i ) pairs occur does not affectRIF BLD+schema valid XML data combined interpretation, permits the truth valuesimplification of the atom. Note that atoms with named aruments are defined only in RIF-BLD , not in RIF-Core nor in RIF-PRD . Editor's Note: If that is deemed useful, it needs some more work, e.g. extendingcondition on the definitioninterpretation of DM-Name to RIF names, dealing with P occurring bothmembership formulas (condition 3). Since subclass formulas are not defined in RIF Core, the positioncondition on the interpretation of a class identifier in amembership or subclass relationship formula, and asformulas (condition 3), in the namedefinition of a relationRIF Core+schema valid XML data combined interpretation, must be extended to account explicitly for all the membership formulas whose interpretation follows, in an atom; etc. Example 4.8. TBCthe RIF BLD+schema valid XML data case, from the axioms on the truth valuation of subclass and membership formulas.

5 Conformance

Editor's Note: This section will be completed in a future draft.

6 The special case of RDF and OWL data sources

Editor's Note: RDF an dOWLand OWL data sources can be imported in RIF documents in two different ways: according to the RIF-RDF-OWL specification, that specifies the combination of RIF documents with RDF and OWL graphs, directly;directly or as an XML document. This section examines how thisthese two ways of importing RDF and OWL documents relate. The section will be completed in a future draft.

7 References

[Infoset]
XML Information Set (Second Edition), John Cowan and Richard Tobin, Editors. World Wide Web Consortium, 04 Feb 2004. This version is http://www.w3.org/TR/2004/REC-xml-infoset-20040204. The latest version is available at http://www.w3.org/TR/xml-infoset.

[RFC 3986]
RFC 3986: Uniform Resource Identifier (URI): Generic Syntax, T. Berners-Lee, R. Fielding, and L. Masinter. January 2005. Available at: http://www.ietf.org/rfc/rfc3986.txt

[RFC 3987]
RFC 3987: Internationalized Resource Identifiers (IRIs), M. Duerst and M. Suignard. January 2005. Available at: http://www.ietf.org/rfc/rfc3987.txt

[RIF-Core]
RIF Core Dialect Harold Boley, Gary Hallmark, Michael Kifer, Adrian Paschke, Axel Polleres, Dave Reynolds, eds. W3C ProposedRecommendation, 11 May22 June 2010, http://www.w3.org/TR/2010/PR-rif-core-20100511/http://www.w3.org/TR/2010/REC-rif-core-20100622/. Latest version available at http://www.w3.org/TR/rif-core/.

[RIF-BLD]
RIF Basic Logic Dialect Harold Boley, Michael Kifer, eds. W3C ProposedRecommendation, 11 May22 June 2010, http://www.w3.org/TR/2010/PR-rif-bld-20100511/http://www.w3.org/TR/2010/REC-rif-bld-20100622/. Latest version available at http://www.w3.org/TR/rif-bld/.

[RIF-PRD]
RIF Production Rule Dialect Christian de Sainte Marie, Gary Hallmark, Adrian Paschke, eds. W3C ProposedRecommendation, 11 May22 June 2010, http://www.w3.org/TR/2010/PR-rif-prd-20100511/http://www.w3.org/TR/2010/REC-rif-prd-20100622/. Latest version available at http://www.w3.org/TR/rif-prd/.

[RIF-RDF-OWL]
RIF RDF and OWL Compatibility Jos de Bruijn, editor. W3C ProposedRecommendation, 11 May22 June 2010, http://www.w3.org/TR/2010/PR-rif-rdf-owl-20100511/http://www.w3.org/TR/2010/REC-rif-rdf-owl-20100622/. Latest version available at http://www.w3.org/TR/rif-rdf-owl/.

[XDM]
XQuery 1.0 and XPath 2.0 Data Model (XDM), M. Fernández, A. Malhotra, J. Marsh, M. Nagy, N. Walsh, Editors. W3C Recommendation 23 January 2007. This version is http://www.w3.org/TR/2007/REC-xpath-datamodel-20070123/. The latest version is available at http://www.w3.org/TR/xpath-datamodel/.

[XML]
Extensible Markup Language (XML) 1.0 (Fifth Edition), T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, F. Yergeau, Editor. W3C Recommendation 26 November 2008. This version is http://www.w3.org/TR/2005/REC-xml-id-20050909/. The latest version is available at http://www.w3.org/TR/REC-xml.

[xml:id]
xml:id Version 1.0, J. Marsh, D. Veillard, N. Walsh, Editors. W3C Recommendation 9 September 2005. This version is http://www.w3.org/TR/2008/REC-xml-20081126/. The latest version is available at http://www.w3.org/TR/xml-id.

[XPath 2.0]
XML Path Language (XPath) 2.0, D. Chamberlin , A. Berglund, S. Boag, et. al., Editors. W3C Recommendation 23 Jan 2007. This version is http://www.w3.org/TR/2007/REC-xpath20-20070123/. The latest version is available at http://www.w3.org/TR/xpath20/.

[XQuery 1.0]
XQuery 1.0: An XML Query Language, D. Chamberlin , A. Berglund, S. Boag, et. al., Editors. W3C Recommendation 23 Jan 2007. This version is http://www.w3.org/TR/2007/REC-xquery-20070123/. The latest version is available at http://www.w3.org/TR/xquery/.

[XSD 1.1 Part 2]
W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes, D. Peterson, S. Gao, A. Malhotra, C. M. Sperberg-McQueen, H. S. Thompson, Editors. W3C Candidate Recommendation 30 April 2009. This version is http://www.w3.org/TR/2009/CR-xmlschema11-2-20090430/. The latest version is available at http://www.w3.org/TR/xmlschema11-2/.

8 Appendix A: Glossary (non-normative)

Editor's Note: This section will be completed in a future draft.

Expanded QName
An expanded QName is a set of three values consisting of a possibly empty prefix, a possibly empty namespace URI, and a local name. (http://www.w3.org/TR/xpath-datamodel/#dt-expanded-qname)
QName
A qualified name is a name subject to namespace interpretation. In documents conforming to this specification, element and attribute names appear as qualified names. Syntactically, they are either prefixed names or unprefixed names. An attribute-based declaration syntax is provided to bind prefixes to namespace names and to bind a default namespace that applies to unprefixed element names; these declarations are scoped by the elements on which they appear so that different bindings may apply in different parts of a document. (http://www.w3.org/TR/REC-xml-names/#dt-qualname)

9 Appendix B: Extract from the XQuery 1.0 and XPath 2.0 Data Model (non-normative)

9.1 Element and attribute node type names (from [XDM])

Editor's Note: This section reproduces the text of Section 3.3.1.1. Element and Attribute Node Type Names in [XDM], for the reader's convenience. Notice that, for the purpose of this specification, the type name is considered unknown, and the [type name] property is left empty, when the [validaty][validity] property does not exist or is "unknown" and the [validation attempted] property does not exist or is "none".

Notation: Some aspects of type assignment rely on the ability to access properties of the schema components. Such properties are indicated by the style {component property}. Note that this does not mean a lightweight schema processor cannot be used, it only means that the application must have some mechanism to access the necessary properties.

The precise definition of the schema type of an element or attribute information item depends on the properties of the PSVI. In the PSVI, [Schema Part 1] defines a [type definition] property as well as the [type definition namespace], [type definition name] and [type definition anonymous] properties, which are effectively short-cut terms for properties of the type definition. Further, the [element declaration] and [attribute declaration] properties are defined for elements and attributes, respectively. These declarations in turn will identify the [type definition] declared for the element or attribute. To distinguish the [type definition] given in the PSVI for the element or attribute instance from the [type definition] associated with the declaration, the former is referred to below as the actual type and the latter as the declared type of the element or attribute instance in question.

The type depends on the declared type, the actual type, and the [validity] and [validation attempted] properties in the PSVI. If:

The prefix associated with the type names is implementation-dependent.

9.2 Typed value determination (from [XDM])

This section describes how the typed value of an Element or Attribute Node is computed from an element or attribute PSVI information item, where the information item has either a simple type or a complex type with simple content. [...]

The typed value of Attribute Nodes and some Element Nodes is a sequence of atomic values. The types of the items in the typed value of a node may differ from the type of the node itself. This section describes how the typed value of a node is derived from the properties of an information item in a PSVI.

The types of the items in the typed value of a node are determined as follows. The process begins with T, the schema type of the node itself, as represented in the PSVI. For each primitive or ordinary simple type T, the W3C XML Schema specification defines a function M mapping the lexical representation of a value onto the value itself.

Note. For atomic and list types, the mapping is the “lexical mapping” defined for T in [Schema Part 2]; for union types, the mapping is the lexical mapping defined in [Schema Part 2] modified as appropriate by any applicable rules in [Schema Part 1]. The mapping, so modified, is a function (in the mathematical sense) which maps to a single value even in cases where the lexical mapping properproperly maps to multiple values.

The typed value is determined as follows:

The typed value determination process is guaranteed to result in a sequence of atomic values, each having a well-defined atomic type. This sequence of atomic values, in turn, determines the typed-value property of the node in the data model.

10 Appendix C: Embedding imported data sources as RIF facts (non-normative)

Editor's Note: This section will be completed in a future draft.

11 Appendix D: Examples using the normative RIF/XML syntax

Editor's Note: This section will be completed in a future draft

12 Appendix E: Change Log (non-normative)