W3C

RIF Combination with XML data

W3C Working Draft 22 June 2010Group Note 11 December 2012

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

A color-coded version of this document showing changes made since the previous version is also available.

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


Abstract

This document, developed by the Rule Interchange Format (RIF) Working Group, specifies how a RIF document can be combined with XML 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 1112 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
  12. 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.Primer

Summary of Changes

The semantics were completely reworked.auto

Please Send Comments

Please Commentsend any comments to public-rif-comments@w3.org (public archive). Although work on this document by 20 July 2010the Rule Interchange Format (RIF) Working Group seeks public feedback on this Working Draft. Please send youris complete, comments to public-rif-comments@w3.orgmay be addressed in the errata or in future revisions. Open discussion among developers is welcome at public-rif-dev@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 DraftGroup Note 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. 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 combinations of RIF documents 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 uses a data model fordata, with or without an associated XML documents, that is a simplified version ofschema. The specification relies on the abstract XQuery 1.0 and XPath 2.0 Data Model [XDM ]. The XQuery 1.0 and XPath 2.0 Data Model (XDM) specifies] to specify what information is accessible in a collectionthe data, and on XPath 2.0 expressions [XPath 2.0] to select pieces of XML documents, butthat information. It does not specify the language usedrelies on XML Schema Component Designators [XSD-CD] expressions to represent or accessprovide unambiguous designators for XML schema types and schema elements in combinations where the data: this document specifiesXML data is associated with an implementation, using the RIF condition language, ofXML schema.

XPath 2.0 is a simplified version of the XDM. This makes the RIF conditionnon-XML expression language comparable to other implementationsthat allows the processing of values conforming to the XDM, such as [ XPath 2.0 ] anddata model defined in [ XQuery 1.0XDM]. LikeThe XQuery 1.0 andresult of an XPath 2.0expression may be a selection of nodes from the input data Model ,model, or an atomic value, or more generally, any sequence allowed by the simplified version used in this document supportsdata model. The following classesname of XML documents: Well-formed documents conforming to [Namespaces in XML] or [Namespaces in XML 1.1]. DTD-valid documents conforming to [Namespaces in XML] or [Namespaces in XML 1.1], and W3C XML Schema-validated documents. Accordingly, this document specifies howthe language derives from its most distinctive feature, the path expression, which provides a RIF document is combined with well-formed, and, wheremeans of hierarchic addressing of the nodes in an XML tree.

XML Schema Component Designators (XSD-CD) is specified, schema-valida non-XML expression language that provides reliable and unambiguous designators for XML documents.schema components. The semantics is independent onspecification divides the provenanceproblem of the XML data inconstructing schema component designators into two parts: defining a combination: it can be imported explicitly indesignator for an assembled schema, and defining a RIF document, or combined on the consumer-side,designator for a particular schema component or schema components, understood relative to a combination of both. However,designated schema. This specification uses only XML schemas thata limited subset of the schema component path expression language, from the second part.

According to this specification, XPath and component designator expressions are explicitly importedrepresented as string constants in RIF formulas. Although the semantics of RIF documentand XML data combinations is specified with respect to any valid XPath 2.0 expression, conforming implementations are taken into account for the interpretationrequired to support only a limited subset. Future versions of the combination.this provides a way to communicatespecification may extend that subset.

The XQuery 1.0 and XPath 2.0 Data Model that(XDM) is intended, in a RIF document, forbased on the infoset [Infoset], possibly augmented with information resulting from the validation of the XML data source, without specifying an actual data source. Section 2 specifies how the rif:Import directive is used to importagainst an XML document and anschema, or post-schema validation infoset (PSVI), according to the specification W3C XML Schema are import in a RIF document.Definition Language (XSD) 1.1 Part 1: Structures [XSD 1.1 Part 1]. An instance of the RIFdata model for XML documents is describedcan also be constructed directly through application APIs, or from non-XML sources such as relational tables in section 3. Section 4 specifiesa standarddatabase. The 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 semanticscombination of RIF PRD combinationsdocuments with XML data is, then, defined, based onapplies, therefore, to the definitioncombination of aRIF BLD+XMLdocuments with non-XML data combined interpretation (section 4.2); finally,as well, where the semantics of RIF Core combinations withXML binding of the data is defined with respectonly used to refer to it in the model-theoretic semanticsinterchanged rules. This is likely to be of particular interest when an XML schema is interchanged along with the combination ofRIF BLDdocument.

Like the XQuery 1.0 and XMLXPath 2.0 Data andModel, the operationalsemantics of the combinationcombinations of RIF PRDdocuments and XML data (section 4.3). Editor's Note: This section will be completedthat is specified in a future draft. 2 Importingthis document supports the following classes of XML data:

Accordingly, this document to be combined with thespecifies how a RIF document that contains the directiveis combined with well-formed -- and, optionally, a profile that governswhere an XML schema is specified, schema-valid -- XML documents. The combination. In [ RIF-Core ], [ RIF-PRD ] and [ RIF-BLD ],semantics is independent on the useprovenance of the Import directive is limited to identifying anXML data in a combination: it can be imported explicitly in a RIF document, or an RDF graph or an OWL ontology to becombined with a RIF document. An optional profile that governson the consumer-side, or a 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 directiveboth. However, only XML schemas that are explicitly imported in four ways:the IRI of any XMLRIF document is allowed as a value ofare taken into account for the location sub-element, that containsinterpretation of the IRI that identifiescombination. This provides a way to communicate the importeddata document; The new value: http://www.w3.org/2007/rif-import-profile#xml-data ,model that is definedintended, in a RIF document, for the profile of an import, indicating that the imported document isdata source, without specifying an XML documentactual data source.

Section 2 specifies a normative standard semantics for RIF combinations with no associatedXML schema; In addition, any IRI that identifiesdata: first, an XML schema documentXPath 2.0 and XSD-CD based syntax is allowed as a profile, identifying the XML schemaspecified, that is associated with the importedused to relate RIF formulas to XML data; Finally,data items in a new value: http://www.w3.org/2007/rif-import-location#no-data ,combinations (section 2.1). Then, a model-theoretics semantics is allowed forgiven to RIF BLD combination with XML data, with and without associated XML schema (section 2.2); the locationoperational semantics of an import, indicating that the directive does not requireRIF PRD combinations with XML data is, then, defined, based on the importdefinition of a RIF BLD+XML data document Editor's Note:combined interpretation (section 2.3); finally, the extended syntaxsemantics of RIF Core combinations with XML data is still under discussion. Other approaches include: (i)defined with respect to makethe location sub-element optional as well; (ii) to reserve new keywords inmodel-theoretic semantics of the http://www.w3.org/2007/rif-import-profile namespace, such as: xml-schema , xml-schema-valid-data , etc,combination of RIF BLD and XML data and to add a specific construct forthe schema locator.operational semantics of the following constraints must be satisfied: If an Importcombination of RIF PRD and XML data (section 2.4).

Section 3 specifies how the rif:Import directive does not requireis extended to support the import of XML data and XML schemas in a RIF document.


Combination with XML data document, the profile must be specified;and/or schema constrains the twointerpretation of RIF formulas and give them special values http://www.w3.org/2007/rif-import-location#no-data , forsemantics. As a result, the location,semantics of RIF when XML data and http://www.w3.org/2007/rif-import-profile#xml-data , for the profile, areschema is imported is not allowed inthe same Import directive; Ifas the profilesemantics of an Import directive identifies anRIF alone, even if the imported XML data and schema are empty.

Section 4 specifies the conformance criteria for this specification.

Implementation of this specification requires a good understanding of XPath 2.0 and ifthe XQuery 1.0 and XPath 2.0 Data Model. However, this document providescan be read and understood without a schema-location ,deep knowledge of these two specifications. For the profile must identifyconvenience of the same XML schema asreader, the schema-location IRI; Ifdefinition of terms from the profile is rif:xml-dataXPath 2.0, XSD-CD and the location must identify an XML document. This specification does not prescribe the behaviour of a conformant implementation when oneXDM specifications, that are of the above constraints is not satisfied.particular importance for this specification does not prescribedocument, are repeated in the behaviour of a conformant implementation when an Import directive contains a profile that is neither rif:xml-data nor an IRI that identifies an XML schema. Example 2.1.Appendix A: Glossary. However, the first three import directives, below,definition in the glossary are valid;non-normative: the fourth is not: Import(http://example.org/customertable.xml http://www.w3.org/2007/rif-import-profile#xml-data) Import(http://example.org/customertable.xml http://example.org/customertable.xsd) Import(http://www.w3.org/2007/rif-import-location#no-data http://example.org/customertable.xsd) Import(http://www.w3.org/2007/rif-import-location#no-data http://www.w3.org/2007/rif-import-profile#xml-data)only normative definitions are as specified in the first directive says that[XPath 2.0] and the rules[XDM] recommendations, and in the importing RIF documentXSD-CD specification. Such terms are to be combinedshown in square bracket, with a superscript indicating XP if the dataterm is defined in XPath 2.0: [thus]XP; or with a superscript indicating XDM if the XMLterm is defined in XDM: [thus]XDM; or with a superscript indicating CD if the term is defined in XSD-CD: [thus]CD.

This document identified byfollows the IRI: http://example.org/customertable.xmlconvention used in other RIF specifications, to start definition with: Definition and that there is no data model associatedend them with the imported datasymbol ☐. In the form of an XML schema.same way, examples start with: Example and end with ☐. The second directive says thatend symbol may be omitted if the rules indefinition or example ends with the importing RIFsection.

Several prefixes are used throughout this document for notational convenience. The following bindings are assumed.

  1. rif bound to be combinedhttp://www.w3.org/2007/rif
  2. xs bound to http://www.w3.org/2001/XMLSchema
  3. xml bound to http://www.w3.org/XML/1998/namespace
  4. fn bound to http://www.w3.org/2005/xpath-functions
  5. pred bound to http://www.w3.org/2007/rif-builtin-predicate
  6. func bound to http://www.w3.org/2007/rif-builtin-function
  7. xscd bound to http://www.w3.org/2009/xmlschema-ref

2 RIF combination with the data in theXML document identified by the IRI: http://example.org/customertable.xml and that there is adata

model associated withThis section specifies the imported data, innormative semantics of the formcombination of RIF formulas and XML data, for RIF Core, RIF PRD and RIF BLD, where the XML schema that is identified by the IRI: http://example.org/customertable.xsd . The third directive says thedata that is combined with the rules is expected tomay be associated with an instance of the data model that is imported as theXML schema identified by the IRI: http://example.org/customertable.xsd ; but the directive does not say whatschema.

Definition (RIF+XML data combination). A RIF+XML data combination is to be combined with the rules. The fourth directive violates one of the constraint: therefore, ita triple <R, E, S>, where R is out of the scope of this specification. Notice that none of the three valid directivesa RIF formula (document or non-document), E is incompatible with the other two, buta, possibly empty, set of data model [nodes]XDM that combiningcontains the first two is confusing and error-prone, and should be avoided; andinformation that the third oneis redundant withrepresented in the second,XML data, and that combining the twoS is useless and confusing, and that it should be avoided. 3 A simple data model fora, possibly empty, set of XML documents This section defines the RIF data modelschema definitions.  ☐

For XML documents (henceforth "the data model").the data model serves two purposes: it specifiespurpose of evaluating the informationXPath 2.0 expressions that is accessible to a RIF consumer in an XML document, possiblyare used, in combination with an XML schema; and it is usedR, to specify the interpretation ofaccess the combination of RIF withXML data. Thedata modelthat is a simplified version ofrepresented in E, the XQuery 1.0[in-scope schema definitions]XP are the schema definitions in S and XPath 2.0all their components.

This specification does not describe or prescribe how the set of data model [[nodes]XDM ]. As, in a consequence, the RIF condition language canRIF+XML data combination, is obtained: it may result from parsing one or more XML documents and/or validating them against one or more XML schemas, or it may be consideredcreated by methods other than parsing and/or schema-validating XML documents.

However, in a partial implementation of the XQuery 1.0 and XPath 2.0RIF+XML data Model, and the interpretationcombination <R, E, S>, any information item in E that represents an instance of the RIF condition languagea schema definition that is an element of S or a component in an element of S, must be valid with respect to XML documents can be specified in termsthat schema definition.

This specification does not prescribe the behaviour of a conformant implementation when the XQuery 1.0 and XPath 2.0set of data model [nodes]XDM in a RIF+XML data combination does not satisfy the above validity constraint, or its implementations, such as XPath 2.0 [ XPath 2.0 ]. This document will reuse definitionsany relevant constraint from the XQuery 1.0 and XPath 2.0 Data Model and theXPath 2.0 specifications, as appropriate, and otherwise provide pointers and examples where relevant. 3.1 Definitions2.0, XDM or XSD-CD specifications.

2.1 Syntax

This section addresses how a RIF formula interacts with the XML data, in a RIF+XML data modelcombination; that is, this section specifies how the information items from theaccess to XML infoset [ Infoset ]data, and from the post-schema validation infoset (PSVI), or derived fromto XML schema information, if available, is represented in RIF formulas, for the infoset andpurpose of combining them.

The PSVI,basic idea is that are required to interpret somethe object-attribute-value semantics of RIF constructs with respect to an XML document. Definition (Information item). (from [ Infoset ]) An information itemframe formulas is an abstract descriptionused, in the combination of some part of anRIF formulas and XML document: each information item has a set of associated named properties.  ☐ In this document, an information item is saiddata, to be constructed from an infoset , ifexploit the data item that it describes is contained inintended semantics of the relation between a data source that is not associated with[context node]XP, an XML schema when it is importedXPath 2.0 expression and the sequence that the expression matches in RIF. Ifthe data source is associated with an XML schema, allcontext of the information items used to describenode: in the contentcontext of that data source are said to be constructed froma PSVI . If an information itemRIF+XML data combination <R, E, S>, frame formulas of the form object["some XPath expression"->val], where the object term is constructed frominterpreted as an infoset, all general and external parsed entities must be fully expanded before thedata model is constructed.[node]XDM in this specification, the property names are shownE, mean that val can be derived, in square brackets, [thus] .a way to be specified in this document, from the data model relies on three typessequence of information items: Element informationitems ,that describethe elementsXPath expression matches in an XML document. The properties associated with each element information item are: [namespace name], [local name], [children], [root], [attributes], [type name], [string value], [typed value], [is-id], [is-idrefs]; Attribute information items , that describethe attributescontext of elements. The properties associated withthe attribute information item are: [namespace name], [local name], [attribute type], [owner element], [type name], [string value], [typed value], [is-id], [is-idrefs]; Character information items , that describenode denoted by object.

This document specifies the semantics of RIF+XML data characters that appearcombinations, in general terms, for any valid XPath 2.0 expression. But some of the XML document. The character information item has two properties: [character code] and [element content whitespace]. Givendetails are specified normatively for a data source, the relevant setlimited subset of information items may be createdXPath 2.0 expressions only. Namely, conforming implementations must support the XPath 2.0 expressions specified by methods other than parsing and/or schema-validating an XML document. This specification does not describe or prescribe any method for retrievingthe required information from a data source, possibly combined with an XML schema.following EBNF grammar:

RIFexpr               ::= StepExpr | ValueExpr | AbbreviatedExpr
AbbreviatedExpr       ::= ElementName | '@' AttributeName
ValueExpr             ::= 'fn:data(' ( StepExpr | '.' ) ')'
StepExpr              ::= StepAxis ( NameTest | KindTest ) ('[' Position ']')?
StepAxis              ::= 'self::' | 'child::' | 'attribute::'
NameTest              ::= ElementName | AttributeName
KindTest              ::= ElementTest
                          | AttributeTest
                          | SchemaElementTest
                          | SchemaAttributeTest
ElementTest           ::= 'element' '(' (ElementNameOrWildcard (',' TypeName '?'?)?)? ')'
SchemaElementTest     ::= 'schema-element' '(' ElementDeclaration ')'
ElementDeclaration    ::= ElementName
AttributeTest         ::= 'attribute' '(' (AttribNameOrWildcard (',' TypeName)?)? ')'
SchemaAttributeTest   ::= 'schema-attribute' '(' AttributeDeclaration ')'
AttributeDeclaration  ::= AttributeName
ElementNameOrWildcard ::= ElementName | '*'
ElementName           ::= QName
AttribNameOrWildcard  ::= AttributeName | '*'
AttributeName         ::= QName
TypeName              ::= QName
Position              ::= [1..9] [0..9]*

Future versions of this specification distinguishes between the data model as a general concept and specific items (information items or atomic values)may extend that subset.

XPath expressions are concrete examples of the data model. For the purpose of this specification, the term instance of the data model willrepresented in RIF as xs:string constants.

Editor's Note: Alternatively, an additional symbol space, rif:xpath, could be used exclusivelyadded to denote such concrete examples of theRIF built-in data modeltypes: in that are sequences of element information itemscase, XPath expressions would be represented as rif:xpath constants.

XPath 2.0 unabbreviated syntax must be used in document order. Definition (Instance ofthe data model). An instance ofnormative RIF/XML syntax, except when the data modelexpression is a sequence of element information items, in document order. In particular, given an XML document D , the instance ofsimple StepExpr and the data model that describes Dtest is the sequence of all the element information itemsa NameTest: in that describe an element containedcase, the abbreviated syntax must be used in D ,the normative RIF/XML syntax.

Both syntaxes, abbreviated and unabbreviated, are allowed in document order.  ☐the non-normative RIF presentation syntax.

When therea string constant is no ambiguity with respect to D , the instance ofevaluated as an XPath expression, the data model that describes D will be called, simply:[statically known namespaces]XP are the instance ofin-scope namespaces for the data model . Definition (Atomic value). An atomic value is a valuecontaining element in the value spaceRIF formula.

Likewise, the object-class and subclass-superclass semantics of an atomic typeRIF member and subclass formulas is labeled withused to exploit the name of that atomic type.  ☐ Definition (Atomic type). An atomic type is oneintended semantics 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.relation between an important characteristicXML element and its XML schema type, and of the data model is that there is no distinctionrelation between an item (atwo XML schema types, when information item or an atomic value )on classes and a singleton sequence containing that item. An itemtypes definitions is equivalent to a singleton sequence containing that item and vice versa. Except when specified otherwise, sequences are ordered according toavailable from imported XML schemas. RIF member formulas of the document order . Definition (Document order). A document order is defined among allform: object #  "an XSD-CD component path expression", where the element information items that describe a given XML document. Document orderobject term is interpreted as a total ordering. Informally, document order is the order in which nodes appear inelement [node]XDM e E, mean that the XML serialization of a document.  ☐ Within a tree, document orderfragment represented by e satisfies the following constraints: The root node is the first node. Every node occurs before all of its children and descendants. The relative order of siblings isXML schema definition designated by the order in which they occurXSD-CD component path expression.

In the [children] propertysame way, subclass expressions of their parent node. Children and descendants occur before following siblings. XML element, attributethe form: "sub" ## "SUP" where, both, "sub" and type names"SUP" are usually represented as XML qualified names, or QNames. However, xs:QName is not a RIF-Core built-in datatype. InXSD-CD schema component path expressions, mean that the data model, all qualified names, including atomic values,schema types Tsub and TSUP, whose definitions are representeddesignated by the XSD-CD expressions "sub" and "SUP", respectively, satisfy [derived-from]XP(Tsub, TSUP), where the pseudo-function derives-from is defined as expanded QNamesin XPath 2.0, section 2.5.4 - Sequence type matching.

Definition (Expanded QName). An expanded QName is a set of three values consistingThis specification specifies the semantics of RIF+XML data combinations that contains such member or subclass formulas for a possibly empty prefix, a possibly empty namespace IRI and a local name.  ☐ Noticelimited subset of XSD-CD expressions, only. Namely, conforming implementations must support absolute XSD-CD expressions that designate schema types, as specified by the prefix is never usedfollowing EBNF grammar:

RIFSchemaComponentPath       ::=  StepSepator RelativeSchemaComponentPath 
RelativeSchemaComponentPath  ::=  Step (StepSeparator RelativeSchemaComponentPath)?
StepSeparator                ::=  '/'
Step                         ::=  AbbrevStep
AbbrevStep                   ::=  AbbrevElementStep | AbbrevTypeStep
AbbrevElementStep            ::=  NameTest
AbbrevTypeStep               ::=  '~' NameTest
NameTest                     ::=  QName | '0'

XSD-CD component path expressions are represented in this document, and expanded QNames willRIF as xs:string constants.

Editor's Note: Alternatively, an additional symbol space, rif:xsd-cd, could be dealt with,added to RIF built-in data types: in all but definition,that case, XSD-CD expressions would be represented 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 appearingrif:xsd-cd constants.

XSD-CD abbreviated syntax must be used in the XML document. One ofnormative RIF/XML syntax. Both abbreviated and unabbreviated syntaxes are allowed in the element information items corresponds tonon-normative RIF presentation syntax.


For the rootpurpose of expanding QNames in NameTests, the element tree, and all other element information itemsin-scope namespace bindings are accessible by recursively following its [children] property. An element information item hasdefined as all the following properties: [namespace name ]declaration in the namespace name, if any,scope of which the element. Ifstring is.


Example 2.1. Consider, for instance, the element does not belong tofollowing rule, that says that an EarlyCustomer is a namespace, this property has no value; [ local name ]Customer whose Account number is lower than 1000 (using the local part ofRIF presentation syntax and XPath abbreviated syntax):

Forall ?x, ?y
   (_EarlyCustomer(?y) :-
   And( ?x["ex:Name" -> ?y]
        Exists ?z (And ?x["ex:Account" -> ?z]
                       External(pred:numeric-less-or-equal(External(xs:integer(?z)) 1000)))))

Consider, further, the element name. This does not include any namespace prefix orfollowing colon; [ 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 andXML fragment, representing data character appearing immediately withinabout customers:

<CustomerTable xmlns="http://example.org/customertable"
               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>
    <PIN> 222 </PIN>
  </Customer>
</CustomerTable>

Assuming, like in all further examples, that the current element. It does not contain other kinds of information items, such as attribute information itemspair (ex, even if<http://example.org/customertable>) belongs to the XML element described bystatically known namespaces when the information item has attributes. IfXPath expressions are evaluated, the element is empty, this list hascombination, under the semantics described below, of the above rule and XML data, with no members; [ root ]associated XML schema, will entail two new facts, namely:

 _EarlyCustomer("John")
 _EarlyCustomer("Jane")

This rule shows how an XPath expression is used, in the element information item that describesrule, as an xs:string constant, e.g.: "ex:Name" or "ex:Account", to access the rootchildren of an element [node]XDM as frame slots.

Notice that, in the XML document. The [root] propertyabsence of classes and types definitions as would be provided by an associated XML schema, NameTest are enough to exploit all the elementinformation itemsthat describe elements containedis avalable in the sameXML document point todata, in the same root element information item, including that root elementcombination. Notice further that, with no typing information item itself. Ifavailable, atomic values retrieved from the [root] property of an element information item points toXML data can only be interpreted as strings. A consequence is that element information item itself, the [root] properties of allsuch values have to be cast into the element information items that are accessible by following its [children] property, recursively, must pointrequired types when used as arguments to that same root element information item; [ attributes ] An unordered set of attribute information items, oneRIF buit-in functions and predicates.

Notice, also, that, for each ofthe attributes of this element. This includes all ofsame reason, member (or subclass) formulas cannot be used in combination with 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 byXML Schema processing, are added to the [attributes]. If the element has no attributes, this set has no members; [ type name ]data: the [type name] property of an element information item is empty if, andonly if,way (based only on the elementinformation itemthat is constructed from an infoset. Ifavailable in the element information item is constructed fromexample) to ensure that only the ex:Name and ex:Account sub-elements of ex:Customer elements are taken into account would be to add a PSVI,frame formula to the type namecondition, to check that the variable ?x is represented bybound to an expanded QName. It is determined as described in Section 3.3.1.1.element and Attribute Node Type Names from [ XDM ] (reproducedthat is, itself, named ex:Customer":

Forall ?x, ?y
   (_EarlyCustomer(?y) :-
   And( ?x["ex:Name" -> ?y]
        ?x["self::ex:Customer"->?x]
        Exists ?z (And ?x["ex:Account" -> ?z]
                       External(pred:numeric-less-or-equal(External(xs:integer(?z)) 1000)))))

Notice that, in appendix 9.1, Element and attribute node type names, for the reader's convenience); [ string value ] The normalised representation ofthe contentabsence of an XML schema against which the element as a string. The string value is calculated as follows: Ifdata must be valid, the element is empty or if itfact ?x["self::ex:Customer"->?x] does not have any character information item children nor descendants, its string valueentail anything with respect to other properties of ?x.

Now, assume that the following XML schema is associated with the zero length string; Else, if the [type name] property ofabove XML fragment:

<xs:schema 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="PIN" type="PIN"/>
  
  <xs:element name="Customer">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="Name"/>
        <xs:element ref="Account"/>
        <xs:element 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>

When the element information itemXML schema is empty, or if the element has a complex type with element-only content, or a complex typeassociated with mixed content, its string value is the string comprised of characters that correspond tothe [character code] properties of each ofdata, in the characterRIF+XML data combination, typing information item children ofcan be taken into account, both, to focus on the element and all its descendants,data that represent customer information (that is, information represented in document order. If the resulting string consists entirely of whitespaceex:Customer elements), and the [element content whitespace] property of the character information items usedto construct itensure that arguments to built-in functions and predicates are true,properly typed. The string value isexample rule could, then, be written as follows (notice that this version of the zero-length string; Else, ifrule uses unabbreviated XPath syntax):

Forall ?x, ?y
    (_EarlyCustomer(?y) :-
    And( ?x # "/ex:Customer"
         ?x["child::schema-element(ex:Name)" -> ?y]
         Exists ?z (And ?x["child::schema-element(ex:Account)" -> ?z]
                        External(pred:numeric-less-or-equal(?z 1000)))))

In that case, the elementassertion of the class membership: ?x # "/ex:Customer", entails that ?x has a simple type or a complex type with simple content: its string value isall the properties that are required to validate against the schema normalized valuedefinition of the element; Note that, if theelement has a typed value, any valid lexical representationex:Customer.

Another rule example, below, shows how another kind of the typed value can beXPath expression, used to determine the [string value] property; [ typed value ] The typed-value is calculatedas follows: If the elementan xs:string constant: "@xml:lang", is empty or if it has element-only children, its typed value is the element itself; more precisely, if an element information item has no character information itemsused, in its [children] property,a RIF+XML data combination, to access an attribute [node]XDM as a frame slot:

Forall ?x, ?y
   (_SpeaksEnglish(?y) :-
   And( ?x["@xml:lang" -> "en"^^xs:language])
        ?x["ex:Name" -> ?y])

Assuming that the value of its [typed value] propertypair (xml, <http://www.w3.org/XML/1998/namespace>) is also in the element information item itself. This is a deviation fromstatically known namespaces, that rule, combined with the XQuery 1.0 and XPath 2.0example XML data Model : the latter document specifiesand XML schema, entails a single new fact:

_SpeaksEnglish("John")

Notice that all the [typed value] asrules, above, are well-formed RIF formulas, that can be validly consumed without being undefined,combined with any XML data and/or XML schemas. In that case, which isof no use in this specification; whereascourse, this specification requires a handle to an element information item,adds nothing to access its [children] and [attributes] properties from its [typed value] (seethe definitionsspecification of combined interpretations in Section 4,the RIF combination with XML data ); Else, ifCore Dialect, as regards the [type name] propertysemantics of the element information item is empty, or if the element has a complex type with mixed content (including xs:anyType), its typed value isrules.

2.2 Model-theoretic semantics of RIF BLD+XML data combinations

The same as its string value; Otherwise,specification of the element must havemodel-theoretic semantics of a simple type orRIF BLD+XML data combination -- a complex type with simple content. Its typed value is computed as described in Section 3.3.1.2 Typed Value DeterminationRIF+XML data combination, in [ XDM ] (reproduced in appendix 9.2, Typed value determination, for the reader's convenience). The result<R, E, S> where R is a sequence of zeroRIF-BLD (document or more atomic values. The relationship betweennon-document) formula -- follows closely the valuesspecification of the [type name], [typed value], and [string value] propertiessemantics of an element information item is consistent with XML Schema validation. Notea RIF BLD formula, except that inthe casenotion of xs:QName s and xs:NOTATION s, the prefix is not preserved, and the typed values are represented as expanded QNames. Thissemantic structures is a minor deviation fromreplaced by the XQuery 1.0 and XPath 2.0notion of RIF BLD+XML data Modelcombined interpretations: informally, RIF BLD+XML data combined interpretations are RIF BLD semantic structures, but this specification does not use the prefix; [is-id] If the [type name] property of an element information item is empty, or if the element has a complex typeextended with element-only content, the [is-id] property is false. Else, if the typed value of the element consists of exactly one atomic value,an additional mapping, IDM, that value is of type xs:IDinterprets data model [nodes]XDM, or a typeand constrained with additional conditions, derived from xs:ID , the [is-id] property is true; otherwise it is false; [is-idrefs] Ifthe [type name] property of an elementinformation 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 valuesin E and S.

2.2.1 Semantic structures

Definition (Semantic structure). For the typed-valuepurpose of defining the element ismodel-theoretic semantics of type xs:IDREF or xs:IDREFS , ora type derived from one of those types, the [is-idrefs] property is true; otherwise it is false. Editor's Note: Although minor, the deviations from the XQuery 1.0 and XPath 2.0RIF BLD+XML 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 Therecombination <R, E, S>, a semantic structure is an attribute information item for each attribute (specified or defaulted) of each element in the document, excluding those which are namespace declarations (because theyas a tuple I = <TV, DTS, D, Dind, Dfunc, IDM, IC, IV, IF, INF, Ilist, Itail, Iframe, Isub, Iisa, I=, Iexternal, Itruth>, where TV, DTS, D, Dind, Dfunc, IC, IV, IF, INF, Ilist, Itail, Iframe, Isub, Iisa, I=, Iexternal and Itruth are not attributes). Attributes declareddefined as in the DTD with no default valueRIF-BLD ([RIF-BLD], section 3.2, Semantic structures), and not specified in the element's start tag are not represented by attribute information items. An attribute information item has the following properties: [ namespace name ] The namespace name, if any,where

2.2.2 Combined interpretation of RIF BLD non-document formulas and XML data

Let Classifiers(S) denote the attribute. Otherwise, this property has no value; [ local name ]set of all the local partwell-formed RIFSchemaComponentPath expressions, expr, such that one of the attribute name. This does not include any namespace prefix orfollowing colon; [ attribute type ] An indication ofholds, where c is the type declared for this attributecomponent selected by expr in the DTD. The only valuescontext of S:

Let, further, Classes(S) Classifiers(S) denote the value ID and its [type name] property does not havesubset of classifier XSD-CD expressions that select the value xs:IDdeclarations of named complex types.

Definition (RIF BLD+XML data combined interpretation). A RIF BLD+XML data combined interpretation is a triple (E, then [ xml:id ] processingI, S), where E is performed. This will assure that the value does have the type ID or xs:ID (if the attribute information itema set of data model [nodes]XDM, possibly empty; S is constructed from an infoset or froma PSVI, respectively)set of XML schema definitions, possibly empty; and that itI is properly normalized.a semantic structure, such that all the [is-id] property is always truefollowing holds:

  1. For attributes named xml:id . Else, if the [attribute type] property hasall the value ID[nodes]XDM e E, or if the type name is xs:ID or a type derived from xs:IDItruth(Iframe(IDM(e))(IC("expr"^^xs:string), RIFValue(e, expr))) = t (true) for any well-formed XPath expression, expr, the [is-id] property is true; otherwise, itfor which RIFValue(e, expr) is false. This specicification does not prescribedefined; and
  2. For all the behaviour ofindividuals o DInd, there is an element [node]XDM with a RIF consumer applicationcomplex type, e E, such that IDM(e) = o, if an error is encountered during [ xml:id ] processing. [ is-idrefs ] Trueand only if the value of the [attribute type] propertythere is IDREF or IDREFSan XSD-CD component path expression, expr Classifiers(S), or if anysuch that Itruth(Iisa(o, IC("expr"^^xs:string))) = t (true) and
  3. DTS is a logically separate information item, but applications are freeextended to chunk characters into larger groups as necessary or desirable. A character information item hasinclude all the following properties: [ character code ]named atomic types defined in the ISO 10646 character code (in[in-scope schema definitions]XP;
  4. Itruth(Isub(IC("T1"^^xs:string), IC("T2"^^xs:string)) = t (true) for all the range 0 to #x10FFFF, though not every value in this rangepairs of XSD-CD component expressions, (T1, T2) Classes(S) × Classes(S), that select two complex types, t1 and t2, such that [derives-from]XP(t1, t2) is a legal XML character code)true;

Notice that clause 2, in the above definition, implies that, if the class membership of an object that interprets the character. [ element content whitespace ][context node]XP e, in a boolean indicating whetherclassifier amongst the characterschema definitions in the combined interpretation is white space appearing within element content (see [ XML ], Section 2.10. White Space Handling). Noteasserted, then the object must have all the properties that validating XML processorsare required to provide this information. If there is no declaration formandated by the containing element, or if there are multiple declarations, or ifclassifier, and no declaration has been read, thisproperty has no value for white space characters. It is always false for charactersthat arethe definition of the classifier does not white space. 3.5 Resolutionallow. This is a consequence of references Definition (Reference information item). Given an information item, Ithe constraint that all the schema element [node]XDM, whose [is-id] is true, and given an atomic value, idin E, must be schema valid.

Editor's Note: Another possibility, to resolve the issue of type ID , IDREF , xs:ID , or xs:IDREF , that matchesincomplete instances, would be to introduce one of the atomicor more null values in I' s [typed value] property,the reference information item identified by idRIF vocabulary, e.g. rif:null.

RIFValue is the element information item, R , such that its [root] property has the same value as the [root] property of Ia total mapping from E × EXPR to Dind, if Iwhere EXPR is an element information item, or asthe [root] propertyset of all the element information item pointedwell-formed XPath expressions. RIFValue(e, expr) associates a value in Dind to bythe [owner element] propertysequence of Idata model [nodes]XDM, if Iin E, that are matched by the XPath expression expr when the [context node]XP is an attribute information element;e and eitherS contains the [is-id] property of R[in-scope schema definitions]XP.

RIFValue is true and its [typed value] property matches id ; ordefined as follows.

Let seq = (i1,...,in) be the [is-id] propertysequence of oneitems matched by expr EXPR in the context of e E, where n 0 is the attribute informationnumber of items in R' s [attributes] propertyseq:


Val interprets items as follows:

In the same order; that is, items 2above, fn:string and 5 infn:data are the data model instance,accessors defined in that order [root]: the element information item itself [attributes]: empty [type name]: (no schema) empty (schema) http://example.org/customertable "some locally unique identifier for the anonymous type ofthe CustomerTable element" [string value]: "John 111 Jane 222 222" [typed value]:Xpath 2.0 and XQuery 1.0 Functions and Operators recommendation [XFO], sections 2.3 and 2.4 (for the element information item itself [is-id]: false [is-idrefs]: false an element information item that describesreader's convenience, the first Customer elementdefinitions are copied, non-normatively, in the document, with the following values for its properties [namespace name]: http://example.org/customertable [local name]: Customer [children]:Glossary.)

A sequenceRIF BLD+XML data combined interpretation (E, I, S) determines the truth value, TVal(E,I,S)(φ), of two element information items, which are items 3 and 4 ina RIF-BLD non-document formula φ combined with the XML data model instance, describing the Namein E and Account sub-elements, respectively,XML schema definitions in that same order [root]: same value asS, like a RIF BLD semantic structure, IBLD, determines the [root] propertytruth value TValIBLD(φ), of the previous element information item [attributes]:a attribute information item representing the xml:lang attribute. The attribute information item has the following values for its attributes: [namespace name]: http://www.w3.org/XML/1998/namespace [local name]: lang [Attribute type]: empty [owner element]: the previous element information item [type name]: (no schema) empty (schema) http://www.w3.org/2001/XMLSchema language [string value]: "en" [typed value]: en [is-id]: false [is-idrefs]: false [type name]: (no schema) empty (schema) http://example.org/customertable "some locally unique identifier for the anonymous type Customer " [string value]: "John 111" [typed value]:RIF-BLD non-document formula φ. The element information item itself [is-id]: false [is-idrefs]: false an element information item representingmapping TVal(E,I,S) is defined from the Name sub-elementset of all non-document formulas to TV, the first Customer elementset of truth values in the document,I, as follows.

Definition (Truth valuation of RIF BLD non-document formulas combined with XML data). Truth valuation of RIF BLD non-document formulas combined with XML data is determined using the following valuesfunction TVal(E,I,S), such that for its properties [namespace name]: http://example.org/customertable [local name]: Name [children]:all RIF BLD+XMl data combination, <φ, E, S>, where φ is a sequence of four character information items, spelling j o h nnon-document RIF BLD formula, TVal(E,I,S)(φ) = TValI(φ), in that order [root]: same valuewhere TValI is as the [root] propertydefined in [RIF-BLD], section 3.4 - Interpretation of non-document formulas, with I being the previous element information item [attributes]: empty [type name]: (no schema) empty (schema) http://www.w3.org/2001/XMLSchema string [string value]: "John" [typed value]: "John" [is-id]: false [is-idrefs]: false an element information item representingsemantic structure in the Account sub-element ofRIF BLD+XML data combined interpretation (E, I, S).  ☐

Example 2.2. Assuming that E contains all the first Customer elementdata model [nodes]XDM in the document, withdata model instance that describes the following values for its properties [namespace name]: http://example.org/customertable [local name]: Account [children]: a sequence of three character information items, spelling 1 1 1 ,XML sample fragment in example 2.1; that order [root]: same value as the [root] property ofetable denotes the previous element information item [attributes]: empty [type name]: (no schema) empty (schema) http://www.w3.org/2001/XMLSchema integer [string value]: "111" [typed value]: 111 [is-id]: false [is-idrefs]: false anelement information itemnode, in E, that describesrepresents the second Customer elementinformation that is serialized in the document; an element information item representingCustomerTable element, in the Name sub-element ofexample XML fragment; and that eJohn denotes the second Customerelement node, in E, that represents the document; an elementinformation item representingthat is serialized in the Accountfirst Customer sub-element of(the one whose Name sub-element contains John), the second Customer elementfollowing ground frames must be true in all the document; an element information item representingRIF BLD+XML data combined interpretations, (E, I, ), that is, where E is constructed from the PIN sub-element ofinfoset only, and where IC(_John) = IDM(eJohn) and IC(_Table) = IDM(etable):

  1. _John ["@xml:lang" -> "en"]
  2. _John ["ex:Name" -> "John"]
  3. _John ["ex:Account" -> "111" ]
  4. _Table ["ex:Customer[1]" -> _John ]

Assuming that S contains all the second Customer elementtop-level schema definitions in the document, with the following values for its properties [namespace name]: http://example.org/customertable [local name]: PIN [children]: a sequence of three character information items, spelling 2 2 2sample schema in example 2.1, ground frames #1 and #3 above must be false in that order [root]: same value asall the [root] property ofRIF BLD+XML data combined interpretations, (E, I, S), everything else being equal; instead, ground frames #1 and #2, below, must be true:

  1. _John ["@xml:lang" -> "en"^^xs:language]
  2. _John ["ex:Account" -> 111 ]

The previous element information item [attributes]: empty [type name]: (no schema) empty (schema) http://example.org/customertable PIN [string value]: "222" [typed value]: 222 [is-id]: false [is-idrefs]: false 4class membership formula #1, below, may be true in a RIF combination with XMLBLD+XML data This section specifiescombined interpretation, (E, I, ), but, in the semanticsabsence of an associated schema definition, the combination of RIF documents and XML data, for RIF Core, RIF PRDstring /ex:Customer does not represent a component designator, and RIF BLD, wherethe XMLclass membership formula has no meaning specific to the RIF BLD+XML data maycombined interpretation. However, that same class membership formula must be associated with an XML schema. Definition (RIF+XML data combination). A RIF+XML data combination is a tuple < R , D 1 , ..., D n >, n 1 , where R is atrue in every RIF document and D 1 , ..., D n are XML documents.   ☐ One use case forBLD+XML data combined interpretations, (E, I, S):

  1. _John # "/ex:Customer"

On the combinationother hand, the class membership formula: _PIN_Jane # "/ex:PIN" must never be true as a consequence of being interpreted under a RIF and XMLBLD+XML data combined interpretations, (E, I, S). Indeed, ex:PIN is whendefined as a RIF document imports explicitly the data to which the rules are to be applied: thissimple type: as such it is not in Classes(S) (nor in Classifiers(S)); but it is, instead, added to DTS.

Example 2.3. Consider the case when the RIF document contains one or more Import directivesfollowing element with mixed-content, where the location identifies explicitly an XML document to be combinedprefix ex is associated with the importing RIF document. InIRI http://example.org/, and assume that case, the combinationan element [node]XDM, e, that represents it is imposed byincluded in E.

<ex:letterBody>
  Thank you for ordering the  producer of<ex:item>widget</ex:item>.
  It should arrive by <ex:arrivalDate>09-09-09</ex:arrivalDate>
</ex:letterBody>

The following fact must be true in any RIF document, as well as theBLD+XML data to becombined with the rules that the RIF document contains. We call that case: producer-side combinationinterpretation, (E, I, S), andsuch that IC(_myLetter) = IDM(e):

Indeed, the RIF document: imported XML data . However,element has a significant use case for RIFmixed content: per [XDM] (section 6.2), its [typed value]XDM is, therefore, its string value as an xs;untypedAtomic, which is rules being published or sharedrepresented, per the definition of RIFValue, above, by that same [string value]XDM as aan xs:string.

2.2.3 Combined interpretation of RIF documentBLD documents and XML data

For consumers to apply them to their own data. In that case,the consumer of a RIF document decides independentlypurpose of the producer to combine the rules contained in theinterpretation of imported documents, RIF document withBLD defines the datanotion of his choice. We refer to that case as: consumer-side combinationsemantic multi-structures, which are nonempty sets, {J,I; Ii1, and toIi2, ...}, of semantic structures that differ only in interpretation of local constants.

In the same way, a RIF-BLD+XML data thatcombination <R, E, S>, is combined withinterpreted using a RIF document as: consumer-sideBLD+XML data . This section specifiescombined multi-interpretation (E, Î, S), where Î is a normative semantics for the combinationnonempty set, {J,I; Ii1, Ii2, ...}, of semantic structures that determine a non-empty set, {(E, J, S), (E, I, S); (E, Ii1, S), (E, Ii2, S), ...} of RIF BLD+XML data combined interpretations that differ only in the interpretation of local constants.

To keep this document simple, and in the same way the definition of truth valuation of RIF BLD formulas combined with XML data, without distinguishing betweenabove, refers to the two cases; that is, independentlydefinition of whethertruth valuation in the XML data to be combined withRIF-BLD recommendation, the definition of a RIF document is imported XMLBLD+XML data or consumer-side XML data, or a combination of both. However, it provides a means to require that consumer-side XML data be valid with respectcombined multi-interpretation refers to an XML schema that is imposed bythe producerdefinition of the RIF document. Editor's Note: ...and thus to interchange, along with the rules, thea semantic multi-structure in [RIF-BLD].

Definition (RIF BLD+XML data model with respect to which they have been designed. And thus, to combinecombined multi-interpretation). A RIF with anyBLD+XML data model that can be represented in an XML Schema (including object models). Explanation, use case and example will be added incombined multi-interpretation is a future draft. Definition (Associated XML schema). An XML document, D itriple, (E, Î, S), where Î is associateda semantic multi-structures as defined in [RIF-BLD] (section 3.5 - Interpretation of documents), with an XML schema , XSDthe additional condition that for each semantic suctrure, i Î, in(E, i, S) is a RIF BLD+XML data combined interpretation.  ☐

Similarly, the contexttruth valuation of a RIF+XML data combination,combination < R , D 1 , ..., D i , ..., D nR, E, S>, n 1 , if and only if one of the followingis true:specified with reference to the truth valuation of a RIF document, R , contains an Import directive, where the location identifies the imported XMLBLD document D i and the profile identifies XSD ;formulas, using the RIF document, RBLD+XML data combined multi-interpretation (E, contains an Import directive, where the location is missing, the profile identifies XSDÎ, and D i isS) in place of a consumer-side XML document that validates against XSD . 4.1 Model-theoretic semanticsRIF-BLD semantic multi-structure.

Definition (Truth valuation of RIF BLD+XML data combinations The model-theoretic semanticsBLD document formulas combined with XML data). Truth valuation of RIF BLD defines a semantic structure as a tuple I = < TV , DTS , D , D ind , D func , I C , I V , I F , I NF , I list , I tail , I frame , I sub , I isadocument formulas combined with XML data is determined using the function TVal(E,Î,S), Isuch that for all RIF BLD+XML data combination <Ρ, E, S>, where Ρ is a document RIF BLD formula, TVal(E,Î,S)(Ρ) = TValÎ(Ρ), I external , I truth >. The specificationwhere TValÎ is as defined in [RIF-BLD], section 3.5 - Interpretation of documents, with Î being the model-theoretic semanticssemantic multi-structure in the RIF BLD+XML data combined multi-interpretation (E, Î, S).  ☐

The notions of model and of logical entailment can be defined for a RIF BLD+XML data combination follows closelycombination, based on the specificationdefinitions of the semanticsmodel and of alogical entailment for RIF BLD document, except that the notion(document and non-document) formulas: (E, Î, S) is a model of semantic structuresa RIF BLD+XML data combination <R, E, S>, if and only if Î is replaced by the notiona model of R, in the sense defined in [RIF-BLD] (section 3.6 - Logical entailment), and (E, Î, S) is a RIF BLD+Xml data combined interpretations : informally,multi-interpretation.

Definition (Model of a RIF BLD+XML data combined interpretations arecombination). A RIF BLD semantic structures, with additional conditions on some of the elements of I . The basic ideaBLD+XML data combined multi-interpretation (E, Î, S) is that piecesa model of importeda RIF BLD+XML data are represented, for the purpose ofcombination with RIF, by information items in instances of the data model. Assertions about the names of XML elements in the imported data, and,<R, E, S>, where defined, their types, are represented using class membership and subclass formulas, in the importingR is a RIF documents. ThisBLD document specifies a subset of the lexical spaces of the symbol spaces rif:iri and xs:NCNameor non-document formula, if and requires that constants whose literals are in that subset be interpreted as classesonly if TVal(E,Î,S)(R) = t (true).  ☐

Definition (Logical entailment of element information items, associated to XML element namesa RIF BLD+XML data combination). Let φ and types. In the same way, assertions aboutψ be (document or non-document) formulas. We say that a RIF BLD+XML data combination <φ, E, S> entails the values of attributesRIF BLD+XML data combination <ψ, E, S>, denoted <φ, E, S> |= <ψ, E, S>, if and sub-elementsonly if every model of XML elements, in the imported data, are represented using frame formulas, inthe importingRIF documents. This document specifiesBLD+XML data combination <φ, E, S> is also a subsetmodel of the lexical spaces ofRIF BLD+XML data combination <ψ, E, S>.  ☐

Notice that, in the symbol spaces rif:iri and xs:NCNamecase where E and requires that constants whose literalsS are inempty, that subset be interpreted as [attribute] and [children] properties of element information items. Example 4.1. Inis, if a RIF document that imports the sampleRIF-BLD formula is combined with an empty XML document from Section 3.6. Example of adata model instance , associated with the correspondingset and an empty set of XML schema,schema definitions, the first rule, below, saysinterpretation of that an EarlyCustomer isRIF BLD formula under a Customer whose Account numberRIF BLD+XML data combined multi-interpretation (, Î, ) 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 XML document were imported without the XML schema,still different from its interpretation under the standard RIF consumer processingBLD semantics as defined in [RIF BLD].

Example 2.4. Let expr be a well-formed XPath 2.0 expression, and let

Notice that <φ, ∅, ∅> |= <ψ, ∅, ∅>, provided that the combination would only have accesspair (fn, http://www.w3.org/2005/xpath-functions) belongs to the string value ofstatically known namespaces when the Account sub-element, without an indication of its type. In that case, to guarantee thatXPath expressions are evaluated; but φ |≠ ψ. This is because the rule behavexs:string constants "expr", "fn:data(expr)" and "fn:data(.)" are interpreted as expected, the producer ofsimple string constants under the standard RIF document would haveBLD semantics, whereas they are interpreted according to addthe information thatXPath 2.0 semantics under the valuesemantics of ?y must be cast intoRIF+XML data combination.

Editor's Note: An integer before being compared as a number. Another example, below, showsalternative, less conservative definition for logical entailment in a ruleRIF BLD+XML data combination would be: Let φ and ψ be (document or non-document) formulas. We say that involvesφ entails ψ in a RIF BLD+XML data combination withif and only if every model (E, Î, S) of any RIF BLD+XML data thatcombination <φ, E, S> is represented as an attribute inalso a model of the XML document.: Forall ?x (_EnglishRec(?x) :-  ?x[<http://www.w3.org/XML/1998/namespace#attribute(lang)> -> "en"^^xs:language]) That rule could be intendedRIF BLD+XML data combination <ψ, E, S>. The use cases for the broader definition remain to mean that, if an item is represented, inbe examined.


2.3 Operational semantics of RIF PRD+XML data combinations

The importedeffect on the operational semantics of a RIF PRD formula of the combination with XML data, by an elementwith or without an attribute named lang in theassociated XML namespace, and the value of that attributeschema, is that all the xs:language constant en , thenground facts that must be true under a RIF BLD+XML data combined interpretation, must be added to the information regardingset of ground facts that item is recorded in english. As inrepresents the specificationstate of RIF BLD, Const denotesthe setfact base.

Notice that, whereas the other clauses affect only the initial state of all constant symbols and Var denotesthe setfact base, clause 2 in the definition of all variable symbols. 4.1.1a RIF BLD+XML data combined interpretation modifies the semantics of RIF BLD non-document formulas and schemaless XML datathe simplest case isAssert action, when the action asserts the membership of a RIF BLD documentnew object in a class that is combined with XML data, without an associated XML schema:interpreted as a schema classifier. Indeed, clause 2, in the definition, implies that case,the object in a membership relationship with an XML schema classifier (element or type) must interpret an instance of the data modelclass: that describesis, the XML data is built fromnew member object must validate against the infoset, and it does not assign a typeschema definition associated to the elements and attributes containedclass. As a consequence, in the XML document. To make the definition simpler, we will write that:context of a RIF constant, c , string-matches the [string value],PRD+XML data combination, <R, E, S>,

Assert( object # ClassExpr )

where ClassExpr Classifiers(S), of an information item, irequires, as a prerequisite, that, for all the XPath 2.0 expressions, expr, in an instancethat select a mandatory sub-element or attribute of the data model, if and only if c isclass, the following fact be true:

object [ "expr" -> value ]

where value has a constantvalue that is valid with type xs:string or a type derived from xs:string and c = s , after white space normalization; a RIF list, l , string-matchesrespect to the [string value], s , of an information item, i , in an instanceschema definition of the data model, if and only if s = L , after white space normalization, where Lselected sub-element or attribute.

Formally, that means that the definition of the RIF-PRD transition relation, defined in [RIF-PRD] (section 3.2, Operational semantics of atomic actions), is modified as follows.

Let W denote the order-preserving concatenationset of all the elementsstates of l , after flattening l , and with a white space added between each element. Example 4.2.the RIF constants "1"^^xs:stringfact base, and " 1 "^^xs:string (noticeL denote the white spaces) string-matchset of all the string value: "1", butground atomic actions in the constants "1"^^xs:integer and "1.0"^^xs:string do not;RIF-PRD action language, as defined in [RIF-PRD].

Let, further, expr-valid<R,E,S>, denote a property of a constant, o Const, with respect to a state of the RIF lists List("1"^^xs:string "little"^^xs:string "white"^^xs:string "dog"^^xs:string) , List("1 little"^^xs:string "white dog"^^xs:string) , List("1"^^xs:string List("little"^^xs:string "white"^^xs:string) "dog"^^xs:string)fact base, w W, all, string-matchin the string value: "1 little white dog"; but none string-matches anycontext of the string values: "little white dog" or "1.0 little white dog". Definition (RIF BLD+schemaless XML data combined interpretation).a RIF BLD+schemaless XMLPRD+XML data combined interpretationcombination <R, E, S>. We say that o is a pair ( {I DM } , I ),expr-valid<R,E,S> in w if and only if expr Classifiers(S) and all the following are true, where {I DM }Φ is a set of element information items constructed from an infoset and whereground atomic formulas that represents w:

Definition (RIF-PRD transition relation in a RIF-PRD+XML data combination). In a RIF-PRD+XML data combination <R, E, S>, the [children] propertysemantics of eRIF-PRD atomic actions is specified by the transition relation <R,E,S> W × L × W. A triple (w, α, w') <R,E,S> if and vonly if w W, w' W, α is a RIF List,ground atomic action, and

The same rank, v ioperational semantics of a RIF PRD+XML data combination is, then, exactly as specified in v and c i[RIF-PRD], except that <R,E,S> replaces RIF-PRD in c , eitherthe [typed value]definition of c i is c i itself and I( v i ) = c i ; orthe [typed value] of c i is not c itransition relation, PRS, and v i string-matchesthat is one of the [string value]components of c i ; For all class membership formulas o # C , where I( o ) = e {I DM }, I truth ( o # C ) = t (true) if I ( C ) = I ( " NAMESPACE # 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] propertiesa RIF-PRD production rule system, PRS (cf. [RIF-PRD], Section 4.2.4, Operation semantics of e .   ☐ Notice that xs:NCName constants are included in the definitiona production rule system).

Notice, further, that, since RIF-PRD, unlike RIF-BLD, allows class membership to allowbe asserted for new objects only, the interpretation of RIF+XML data combinations whereobject in such an assertion cannot have some or all elements or attributesthe required properties already. As a consequence, all the mandatory properties must be asserted in the same action block where the class membership is asserted.

Formally, the consequence is that the combination with schema-valid XML data are notputs an additional well-formedness constraints on RIF-PRD action blocks.

Definition (Well-formed action block in a namespace. As defined in [RIF-DTB], the lexical space of rif:iri consists of all absolute IRIs as specifiedRIF-PRD+XML data combination). In [ RFC-3987 ]; asa consequence,RIF-PRD+XML data combination <R, E, S>, an action block is well-formed if and only if it does not allow the representations of local names without namespaces. Editor's Note:is a well-formed RIF-PRD action block, according to the definition will be further commentedin [RIF-PRD] (section 3.1.3 - Well-formed action blocks) and explainedit satisfies the following additional constraint:

Editor's Note: Strictly speaking, since actions are ordered in RIF-PRD action blocks, and undersince the operational semantics for RIF BLD+schemaless XML data combinations as specified above,of atomic actions is defined with respect to a production rule system state, independently from the followingsystem state being a system cycle state or a system transitional state, the ground frame formulas that are required to make o expr-valid<R,E,S> in a state of facts mustshould be true in all the interpretations whereasserted before the specified conditions hold:membership formula is. However, it is conjectured that is, for each fact, f , I truth ( f ) = t in all interpretations, I , wherethe specified conditions hold.atomic actions in an action block that satisfies the facts mayweaker constraint can, always, be true in other interpretations as well, but notre-ordered to satisfy the stronger constraint, without otherwise affecting the semantics of the action block as a consequence ofwhole; whence the combination (NB:absence of the examples use RIF non-normative presentation syntax, and,ordering constraint in particular,the shortcut presentation syntax for RIF constants,above definition.

See also the (non-normative) appendix on embedding XML data as described inRIF Data Types and Builtins, Section 2.2.2. Shortcutsfacts for constants in RIF's presentation syntax ; see Appendix D: Examples usingan exhaustive description of the RIF/XML normative syntax ): _Customer_John [<http://www.w3.org/XML/1998/namespace#attribute(lang)> -> "en"^^xs:language] mustfacts to be true in all interpretations, I , where I C maps _Customer_John on the second element in I DM (representingadded to the first element Customer ininitial state of the sample XML data); _Customer_John [<http://www.w3.org/XML/1998/namespace#attribute(lang)> -> "en"] ) must also be true in all these interpretations, since the [string value] of the xml:lang attribute matches the literal of the xs:string constant "en" ; _Customer_John [ <http://example.org/customertable#Name> -> "John" ]fact base that is requiredto be true in all interpretations where I C maps _Customer_John oncombined with the second element in I DM ; _Customer_John [<http://example.org/customertable#Account> -> 111 ] is not required to be true, evenXML data.

Example 2.5. In interpretationsa RIF-PRD+XML data combination <R, E, S>, where I C maps _Customer_John onS contains all the second elementtop-level definitions in I DM : indeed,the [string value] ofXML schema in example 2.1 (all the sub-element Account ofexamples assume that element isthe string: 111pair (ex, whereas the slot value, in<http://example.org/customertable>) belongs to the example frame, is[statically known namespaces]small>XP</small> when the xs:integer 111 ,XPath and onlyXSD-CD expressions are evaluated):

Do ((?newPin New())
    Assert(?newPin["self::ex:PIN"->999]) )
Do ((?newPin New())
    Assert(?newPin["self::ex:PIN"->"999"^^ex:PIN]) )

(ex:PIN is an xs:string constant can string-matchatomic type defined in S. As a string value; _CustomerTable [<http://example.org/customertable#list(Customer)> -> List(_Customer_John, _Customer_Jane) ]consequence, it is included, per clause 3 in all interpretations where I C maps _CustomerTable onthe root elementdefinition of I DM , _Customer_John on the second element, and _Customer_Jane on the fifth element (representing the second element Customera RIF BLD+XML data combined interpretation, in the sample XML data, whose Name sub-element contains the sequenceset of characters: Jane ); _Customer_John # <http://example.org/customertable#Customer> , in all the interpretations where I C maps _Customer_John on the second or fifth element in I DM ; _Name_Johndata types that are taken into account to interpret RIF formulas.)

Do ((?newPin New())
    Assert(?newPIN #  <http://example.org/customertable#Name> , in all the interpretations where I C maps _Name_John on"/ex:PIN") )

(Since ex:PIN is a simple type, the third or sixth element in I DM ; "John" # <http://example.org/customertable#Name>XSD-CD expression /ex:PIN is not required to be truein any interpretation, because, perClassifiers(S). As a consequence, the semantics ofclass membership assertion, in the xs:string data type in RIF, the xs:string constant "John" cannot be mapped on an element information item in I DM ; _Customer_John = <myNamespace#ID0001> in allexample above, adds no well-formedness constraint that is specific to the interpretations where I C ( _Customer_JohnRIF PRD+XML data combination: its semantics are standard.)

Do ((?newCust New())
    Assert(?newCust # "/ex:Customer")
    Assert(?newCust["ex:Name"->"Jojo"])
    Assert(?newCust["ex:Account"->1111])
    Assert(?newPin["ex:PIN"->999])
    Assert(?newCust["@xml/lang"->"fr"^^xs:language]) )
 = I C ( <myNamespace#ID0001>Do ((?newCust New())
    Assert(?newCust # "/ex:Customer")
    Assert(?newCust["ex:Name"->"Jojo"])
    Assert(?newCust["ex:Account"->1111])
    Assert(?newCust["@xml/lang"->"fr"^^xs:language]) )
Do ((?newCust New())
    Assert(?newCust # "/ex:Customer")
    Assert(?newCust["ex:Name"->"Jojo"])
    Assert(?newCust["ex:Account"->1111])
    Assert(?newPin["ex:PIN"->-5])
    Assert(?newCust["@xml/lang"->"fr"^^xs:language]) )

(-5 is out of range for an ex:PIN value)

Do ((?newCust New())
    Assert(?newCust # "/ex:Customer")
    Assert(?newCust["ex:Name"->"Jojo"])
    Assert(?newCust["ex:Name"->"Le balafré"])
    Assert(?newCust["ex:Account"->1111])
    Assert(?newCust["@xml/lang"->"fr"^^xs:language]) )

(The schema definition requires a namespace, thesingle ex:Name value for each ex:Customer information item).

2.4 Semantics of RIF+XMLRIF Core+XML data combinations

would require that the following facts be true, all other required conditions being satisfied: _Customer_John [ "Name" -> "John" ] _CustomerTable [ list("Customer") -> List(_Customer_John, _Customer_Jane) ] _Customer_John # "Customer" _Name_John # "Name" Example 4.4. Consider the following element with mixed-content,RIF Core is a syntactic subset of RIF BLD, and assume thatthe elementsemantics of RIF Core+XML data combinations is contained in aidentical to the semantics of RIF BLD+XML data sourcecombinations for that subset.

RIF Core is imported inalso a syntactic subset of RIF document, without a namespace nor an associated XML schema: <letterBody> Thank you for ordering the <item>widget</item>. It should arrive by <arrivalDate>09-09-09</arrivalDate> </letterBody> I truth must, underPRD, and the semantics specified above, map the fact: _myLetter["letterBody" -> "Thank you for ordering the Widget. It should arrive by 09-09-09"] , to true in any interpretationof the RIF+XML data combination that maps theRIF local constant _myLetter to an element information item that describes, in theCore+XML data model instance, the parent element ofcombinations is also identical to the above letterBody element. 4.1.2 Combined interpretationsemantics of RIF BLD non-document formulas and schema valid XMLPRD+XML data In the case where a RIF BLD document is combined withcombinations for that subset.

3 Importing XML data that is associated with anand XML schema,schemas in RIF

In RIF, the instanceImport directive is used to communicate the location of an external document to be combined with the data modelRIF document that describes the imported XML data is built fromcontains the PSVI, and it does ascribedirective and, optionally, a type toprofile that governs the elements and attributes containedcombination.

In [RIF-Core], [RIF-PRD] and [RIF-BLD], the XML document. The semanticsuse of these combinations are, essentally, the same as inthe schemaless case, except that values are compared using their typed values instead of their string values, and additional conditions are imposed on I truth to take into account information thatImport directive is specificlimited to the PSVI. Accordingly, andidentifying an imported RIF document. [RIF-RDF-OWL] extends it to makepermit the definition simpler, we will write that:identification of an RDF graph or an OWL ontology to be combined with a RIF constant, c , type-matchesdocument. An optional profile that governs the [typed value]combination of a RIF document with an information item, i , inRDF graph or an instance ofOWL ontology can also be provided, as specified in [RIF-RDF-OWL].

This specification extends the Import directive further to permit the identification of XML data model, if and only ifand/or XML schemas to be combined with a RIF document.

One use case for the typecombination of c , T c ,RIF and XML data is when a RIF document imports explicitly the typedata with which the rules are to be combined: in that case, the combination is identifiedimposed by the expanded QName in the [type name] propertyproducer of i , T i , have a non-empty intersection, and c andthe [typed value] of i areRIF document, as well as the same value indata to be combined with the intersection of T c and T i ; a RIF list, l , type-matchesrules that the [typed value] of an information item, iRIF document contains. We call that case: producer-side combination, in an instance ofand the XML data model, if and only ifto be combined with the type of iRIF document: imported XML data.

However, a significant use case for RIF is rules being published or shared as a list type andRIF document for consumers to combine them with their own data: in that case, the elementsconsumer of l type-match, one-to-one and ina RIF document order,decides independently of the atomic valuesproducer to combine the rules contained in the [typed value]RIF document with the data of i , after flattening l . In additionhis choice. We will write, in the following definition,refer to that two strings, a namespacecase as: consumer-side combination, and an NCName, match, possibly modulo a substitution, the values of, respectively,to the [namespace name] and [local name] of an element information item, e , if eitherdata that is combined with a RIF document as: consumer-side data.

3.1 The namespace and NCName areextended Import directive

Specifically, the values of, respectively,Import directive is extended as follows:

The following additional conditions: {I DM } D Ind ; For all frame formulas o [ slot -> v ] , where I( o ) = e {I DM } , I truth ( o [ slot -> v ] ) = t (true)constraints must be satisfied:

This specification does not prescribe the [children] propertybehaviour of e , and v isa RIF List, and v has the same length as the sub-list, c ,conformant implementation when one of the [children]above constraints is not satisfied.

This specification does not prescribe the behaviour of e , thata conformant implementation when an Import directive contains only the element information items whose [namespace name] and [local name] properties are matched, possibly moduloa substitution, by, respectively, NAMESPACE and NAME , in document order, and for each pair of elements of the same rank, v i in v and c i in c , either the [typed value] of c ilocation that is c i itselfneither http://www.w3.org/2007/rif-import-location#consumer-side-data nor an IRI that identifies an XML document. And I( v i ) = c i ; or the [typed value] of c i isthis specification does not c i , and v i type-matchesprescribe the [typed value] of c i ; For all class membership formulas o # C , where I( o ) = e {I DM }, I truth ( o # C ) = t (true) if onebehaviour of the following is true I ( C ) = I ( " NAMESPACE # NAME "^^rif:iri ), or I ( C ) = I ( " NAME "^^xs:NCName ) and NAMESPACEa conformant implementation when an Import directive contains a profile that is empty, where NAMESPACE and NAME are the values, respectively, ofneither http://www.w3.org/2007/rif-import-profile#xml-data nor an IRI that identifies an XML schema.

Example 3.1. The [namespace name] andfirst three import directives, below, are valid; the [local name] properties of e ; or I ( C ) = I ( " NAMESPACE #type( NAME )"^^rif:iri ), or I ( C ) = I ( "type( NAME )"^^xs:NCName ) and NAMESPACEfourth is empty, where NAMESPACE and NAME are, respectively,not:

  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#consumer-side-data http://example.org/customertable.xsd)
  4. Import(http://www.w3.org/2007/rif-import-location#consumer-side-data http://www.w3.org/2007/rif-import-profile#xml-data)

The namespace andfirst directive says that the local namerules in e 's [type name] property; DTS is extendedthe importing RIF document are to include allbe combined with the simple types, whether built-in XML schema or defineddata in one ofthe XSD i , that are mentioned inXML document identified by the [type name] property of anyIRI: http://example.org/customertable.xml and that there is no data model associated with the imported data in the form of an XML schema.

The information itemssecond directive says that the rules in the importing RIF document are to be combined with the data model instance. For all subclass formulas sub ## SUP , where subin the XML document identified by the IRI: http://example.org/customertable.xml and SUP are distinct constants of type rif:iri or xs:string , orthat there is a type derived from rif:iri or xs:string , I truth ( sub ## SUP ) = t (true) if onedata model associated with the imported data, in the form of the following is true: I ( sub ) = I ( " NAMESPACE sub #type( NAME sub )"^^rif:iri ), or I ( C ) = I ( "type( NAME sub )"^^xs:NCName ) and NAMESPACE subXML schema that is empty, where NAMESPACE sub and NAME sub are, respectively,identified by the values ofIRI: http://example.org/customertable.xsd.

The target namespace and name of an element, e sub defined in XSD , one ofthird directive says the XSD i and either I ( SUP ) = I ( " NAMESPACE SUP # NAME SUP "^^rif:iri ), or I ( C ) = I ( " NAME SUP "^^xs:NCName ) and NAMESPACE SUPdata that is empty, where NAMESPACE SUP and NAME SUP are, respectively,combined with the valuesrules is expected to be an instance of the target namespace and name of an element, e SUP defined in XSD , and e subdata model that is defined in a substitution group whereimported as the head element is e SUPXML schema identified by the IRI: http://example.org/customertable.xsd; or I ( SUP ) = I ( " NAMESPACE SUP #type( NAME SUP )"^^rif:iri ), or I ( C ) = I ( "type( NAME SUP )"^^xs:NCName ) and NAMESPACE SUPbut the directive does not say what data is empty, where NAMESPACE SUPto be combined with the rules.

The fourth directive violates the first and NAME SUP are, respectively,second constraints: the valuesdummy location consumer-side-data, that indicates that the profile is to be applied to consumer-side data, is incompatible with the profile xml-data. Therefore, the directive is out of the target namespace and namescope of an XML schema type, T SUPthis specification.

3.2 Interpretation of Imports

For the purpose of interpreting the combination of a RIF document, R, defined in XSD (not including built-in XML schema data types),and T SUP isXML data, let dataLocation(R) denote the type declaredset of the URIs in the definitionlocation sub-elements of e sub ,the import directives, in XSD ; or I ( sub ) = I ( " NAMESPACE sub #type( NAME sub )"^^rif:iri ), or I ( C ) = I ( "type( NAME sub )"^^xs:NCName ) and NAMESPACE sub is empty,R and I ( SUP ) = I ( " NAMESPACE SUP #type( NAME SUP )"^^rif:iri ),in the RIF documents that are imported, directly or I ( C ) = I ( "type( NAME SUP )"^^xs:NCName ) and NAMESPACE SUPindirectly, in R, whose profile is empty, where NAMESPACE subeither rif:xml-data or identifies an XML schema; and NAME sub are, respectively,let dataDocuments(R) denote the valuesset of the target namespace and namedocument [nodes]XDM in the instances of and XML schema type, T sub , definedthe data model that encapsulate the information in XSD (not including built-inall the XML schema data types), and NAMESPACE SUP and NAME SUP are, respectively,documents that are identified by an URI in dataLocation(R). If dataLocation(R) contains the valuesdummy URI http://www.w3.org/2007/rif-import-location#consumer-side-data, dataDocuments(R) includes, also, the document [node]XDM in an instance of the target namespace and namedata model that encapsulates the consumer-side data. In the absence of consumer-side data, the document node bears no information.

If an Import directive identifies an XML schema type, T SUPas its profile, defined in XSD (not including built-in XML schemathe corresponding instance of the data types), and T sub is derived by restriction or by extensionmodel includes the information from T SUP .   ☐ Editor's Note:the case defined byPSVI that results from validating the first bullet under 2.b and 2.c could be further refined, to differentiate betweenXML data referenced in the case of an empty element andlocation against that schema. Otherwise, the caseinstance of the null value: indata model is built from the latter case,infoset.

If an Import directive has the schema must definevalue: http://www.w3.org/2007/rif-import-location#consumer-side-data as a nillable content for the element. Shall we leavelocator, the interpretation toinstance of the implementations or shall we include it indata model that spec?encapsulates the consumer-side data, if any, includes the latter, we must include a rif:NULL constant in every symbol space... Editor's Note: Condition 4 will be further refined in a future draft, to account forinformation from the problem posed byPSVI that results from validating the inclusion of somedata types in a RIF interpretation, e.g. xs:duration. Editor's Note:against the definition will be further refinedXML schema identified in the profile of that directive.

As a future draftconsequence, if different Import directives associate different XML schemas to account for cases such as xs:anyType typed elements. Editor's Note:the definition will be further commented and explained in a future draft.consumer-side data, the truth valuationinstance of a well-formed RIF BLD formula, φ , under a RIF BLD+schema valid XMLthe data combined interpretation ( {I DM } , I ) is determined by I truth exactly as specified formodel that encapsulates the interpretation of RIF BLD non-document formulas (but withconsumer-side data, if any, includes the definition of I truth as modified byinformation from the combination with XML data). Example 4.5. Following up on Example 4.3 , above, but assumingPSVI that results from validating the RIF BLD document is combined withdata against the sampleXML data, associated withschema that results from importing or including, into an otherwise empty schema, all the XML schema, asschemas identified in Section 3.6. Examplethe profile sub-elements of Import directives with the value: http://www.w3.org/2007/rif-import-location#consumer-side-data as a locator.

Given a RIF document, R, the set of data model instancenodes, E, in the following hold with respect toRIF+XML data combination <R, E, S> is the interpretationset of sample facts, underall the semanticsdocument nodes in dataDocuments(R), and of all the RIF BLD+schema valid XMLdata combination: _Customer_John [<http://www.w3.org/XML/1998/namespace#attribute(lang)> -> "en"^^xs:language] mustmodel nodes that can be truereached from those document nodes.

In all interpretations, Ithe same way, S, where I C maps _Customer_John onthe second elementschema definitions component in I DM (representingthe first element CustomerRIF+XML data combination <R, E, S>, includes all the top level schema definitions found in the sampleXML data); but _Customer_John [<http://www.w3.org/XML/1998/namespace#attribute(lang)> -> "en"] ) must not, sinceschemas that are imported as the xs:string constant "en" does not type-matchprofile of an import directive in R or in a RIF document that is imported, directly or indirectly, in R.

For the xs:language [typed value]: en ; _Customer_John [<http://example.org/customertable#Account> -> 111 ] must be truepurpose of evaluating XPath 2.0 expressions, when interpreting a RIF+XML data combination <R, E, S>, the [in-scope schema definitions]XP include all the schema definitions in S, all interpretations where I C maps _Customer_John onthe secondschema type, schema element and schema attribute definitions that are components of the top level definitions in I DM (but, e.g. _Customer_John [<http://example.org/customertable#Account> -> "111" ] must not); _PIN_Jane # <http://example.org/customertable#type(PIN)> must be true inS, and all interpretations where I C maps _PIN_Jane onthe eighth (and last) elementschema types defined in I DM[XSD 1.1 Part2].

Example 3.2. Continuing example 3.1, above, notice that _PIN_Jane # <http://www.w3.org/2001/XMLSchema#type(integer)> is never required to be true in any interpretationnone of the example RIF BLD+schemathree valid XML data combination, even in interpretations where I C maps _PIN_Jane on the last element in I DM , although the XML schema type http://example.org/customertable#PINdirectives is derived by restriction from xs:integer .incompatible with the other two, but that is because xs:insteger is not defined incombining the associated XML schema ( "the namespace of Cfirst two is confusing and NAME [must] match, respectively, the target namespaceerror-prone, since directive #2 supersedes directive #1. Including effectively useless directives should be avoided.

Combining directive #2 and #3 says that the name of an XML schema type defined in XSD (not including built-in XML schema data types)" , condition 4.brules in the definition of RIF BLD+schema valid XML data combined interpretations ). 4.1.3 Combined interpretation of RIF BLD documents and XMLimporting document are meant to be applied only to data Editor's Note: The definition ofthat validates against the combined interpretation of non-document RIF BLD formulas andXML data,schema in example 2.1, where some ofthe XMLdata is associated with animported or from the consumer-side.

4 References

[Infoset]
XML schemaInformation Set (Second Edition), John Cowan and someRichard Tobin, Editors. World Wide Web Consortium, 04 Feb 2004. This version is not, follows directly from the definitions ofhttp://www.w3.org/TR/2004/REC-xml-infoset-20040204/. The schemalesslatest 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 schema valid cases. It will be developed explicitly in a future draft. A RIF+XML data combination < R , D 1 , ..., D n >, n 0 , where R is an RIF BLD document, and the D i , 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 interpreted using a RIF BLD+XML data combined interpretation ( {I DM } , Î ), where: {I DM } = 1...n {I DM i } , the union of all the sets, {I DM i } , 1 i n , of all the element information items in the instances of the data model that represent, each, one of the XML documents in ( D 1 , ..., D n ); Î is a semantic multi-structure that is defined exactly as specified for the interpretation of RIF BLD document formulas, except that the I truth component in each semantic structure, I , contained in Î , is subject to the additional conditions required for the combined interpretation ( {I DM } , I ). The truth valuation of a RIF+XML data combination < R , D 1 , ..., D n >, n 0 , is determined exactly as specified for the truth valuation of a RIF BLD document formulas, using the RIF BLD+XML data combined interpretation ( {I DM } , Î ) in place of a semantic multi-structure. In the same way, the notions of model and of logical entailment are defined for a RIF BLD+XML data combined interpretation, using exactly the same definition as specified for RIF BOLD (document and non-document) formulas, where the semantic multi-structure, Î , is replaced by the RIF BLD+XML data combined interpretation ( {I DM } , Î ). Notice that, in the case where no XML data is imported, that is, if n = 0 , {I DM } is empty, and the interpretation of a RIF BLD document under a RIF BLD+XML data combined interpretation ( , Î ) is strictly equivalent to its interpretation under the standard RIF BLD semantics. 4.2 Operational semantics of RIF PRD+XML data combinations The effect of the combination with XML data, with or without an associated XML schema, on the operational semantics of a RIF PRD document, is that a ground fact, f , must be added to the set of ground facts that is associated with the state of the fact base that is to be combined with the XML data, if it is true under a RIF BLD+XML data combined interpretation, as defined in the previous section (schemaless or schema valid case, depending on whether the XML data is associated with an associated schema or not). See also the (non-normative) appendix on embedding XML data as RIF facts for an exhaustive description of the facts to be added to the initial state of the fact base that is to be combined with the XML data. Editor's Note: The definition will be further commented and explained in a future draft. Example. Editor's Note: Examples will be added in a future draft. 4.3 Semantics of RIF Core+XML data combinations RIF Core is a syntactic subset of RIF BLD, and the semantics of RIF Core+XML data combinations is identical to the semantics of RIF BLD+XML data combinations for that subset. RIF Core is also a syntactic subset of RIF PRD, and the semantics of RIF Core+XML data combinations is also identical to the semantics of RIF PRD+XML data combinations for that subset. Notice, in particular, that the condition on the interpretation of subclass formulas, condition 5 in the definition of a RIF BLD+schema valid XML data combined interpretation, permits the simplification of the condition on the interpretation of membership formulas (condition 3). Since subclass formulas are not defined inL. 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, the condition on the interpretation of membership formulas (condition 3), in the definition of aCore Dialect Harold Boley, Gary Hallmark, Michael Kifer, Adrian Paschke, Axel Polleres, Dave Reynolds, eds. W3C Proposed Edited Recommendation, 11 December 2012, http://www.w3.org/TR/2012/PER-rif-core-20121211/. Latest version available at http://www.w3.org/TR/rif-core/.

[RIF-BLD]
RIF Core+schema valid XML data combined interpretation, must be extended to account explicitly for all the membership formulas whose interpretation follows, in theBasic Logic Dialect Harold Boley, Michael Kifer, eds. W3C Proposed Edited Recommendation, 11 December 2012, http://www.w3.org/TR/2012/PER-rif-bld-20121211/. Latest version available at http://www.w3.org/TR/rif-bld/.

[RIF-DTB]
RIF BLD+schema valid XML data case, from the axioms on the truth valuation of subclassDatatypes and membership formulasBuilt-Ins 1.0 Axel Polleres, Harold Boley, Michael Kifer, eds. W3C Proposed Edited Recommendation, 11 December 2012, http://www.w3.org/TR/2012/PER-rif-dtb-20121211/. 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 and OWL data sources can be imported inLatest version available at http://www.w3.org/TR/rif-dtb/.

[RIF-PRD]
RIF documents in two different ways: according to the RIF-RDF-OWL specification, that specifies the combination ofProduction Rule Dialect Christian de Sainte Marie, Gary Hallmark, Adrian Paschke, eds. W3C Proposed Edited Recommendation, 11 December 2012, http://www.w3.org/TR/2012/PER-rif-prd-20121211/. Latest version available at http://www.w3.org/TR/rif-prd/.

[RIF-RDF-OWL]
RIF documents withRDF and OWL graphs, directly or as an XML document. This section examines how these two ways of importing RDFCompatibility Jos de Bruijn, Chris Welty, eds. W3C Proposed Edited Recommendation, 11 December 2012, http://www.w3.org/TR/2012/PER-rif-rdf-owl-20121211/. Latest version available at http://www.w3.org/TR/rif-rdf-owl/.

[XDM]
XQuery 1.0 and OWL documents relate.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 section will be completed in a future draft. 7 References [Infoset] XML Information Set (Second Edition)latest version is available at http://www.w3.org/TR/xpath-datamodel/.

[XFO]
XQuery 1.0 and XPath 2.0 Functions and Operators, John CowanAshok Malhotra, Jim Melton, and Richard Tobin,Norman Walsh, Editors. World Wide Web Consortium, 04 Feb 2004.23 Jan 2007. This version is http://www.w3.org/TR/2004/REC-xml-infoset-20040204http://www.w3.org/TR/2007/REC-xpath-functions-20070123/. The latest version is available at http://www.w3.org/TR/xml-infosethttp://www.w3.org/TR/xpath-functions/.

[ RFC 3986 ] RFC 3986: Uniform Resource Identifier (URI): Generic Syntax[XML]
Extensible Markup Language (XML) 1.0 (Fifth Edition), T. Berners-Lee, R. Fielding, and L. Masinter. JanuaryBray, 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.ietf.org/rfc/rfc3986.txt [ RFC 3987 ] RFC 3987: Internationalized Resource Identifiers (IRIs)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 1]
W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures, D. Beech, M. Duerst andMaloney, H. S. Thompson, C. 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.Sperberg-McQueen, S. Gao Gao, N. Mendelsohn, Editors, W3C Recommendation, 22 June 2010, http://www.w3.org/TR/2010/REC-rif-core-20100622/5 April 2012, http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/. Latest version available at http://www.w3.org/TR/rif-core/http://www.w3.org/TR/xmlschema11-1.

[RIF-BLD] RIF Basic Logic Dialect Harold Boley, Michael Kifer, eds.[XSD 1.1 Part 2]
W3C Recommendation, 22 June 2010, 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.XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes, D. Peterson, S. Gao Gao, H. S. Thompson, P. V. Biron, A. Malhotra, A. Malhotra, C. M. Sperberg-McQueen, Editors, W3C Recommendation, 22 June 2010, http://www.w3.org/TR/2010/REC-rif-prd-20100622/5 April 2012, http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/. Latest version available at http://www.w3.org/TR/rif-prd/http://www.w3.org/TR/xmlschema11-2/.

[RIF-RDF-OWL] RIF RDF and OWL Compatibility Jos de Bruijn, editor.[XSD-CD]
W3C Recommendation, 22 June 2010, http://www.w3.org/TR/2010/REC-rif-rdf-owl-20100622/XML Schema Definition Language (XSD): Component Designators, , Editors. W3C Candidate Recommandation 19 January 2010. W3C Recommendation 23 Jan 2007. This version is http://www.w3.org/TR/2010/CR-xmlschema-ref-20100119/. The latest version is available at http://www.w3.org/TR/rif-rdf-owl/http://www.w3.org/TR/xmlschema-ref/.

[XDM] XQuery 1.05 Appendix A: Glossary (non-normative)

component-kind() (from [XSD-CD], section 4.5.1)
The component-kind accessor returns an expanded name identifying the kind of the schema component.

component-name() (from [XSD-CD], section 4.5.2)
The component-name accessor returns zero or one xs:QName values giving the name of the component.

Context node (from [XPath 2.0], section 2.1.1)
The context item is the item currently being processed. An item is either an atomic value or a node. When the context item is a node, it can also be referred to as the context node.

Declared type (from [XDM], section 3.3.1.1)
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 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/ .attributes, respectively. These declarations in turn will identify 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/ .[type definition] declared for 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/ .element or attribute. To distinguish 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/ .[type definition] given in the latest versionPSVI for the element or attribute instance from the [type definition] associated with the declaration, the former is availablereferred to below as the actual type and the latter as the declared type of the element or attribute instance in question.

derived-from (from [XPath 2.0], section 2.5.4)
[The] pseudo-function named derives-from(AT, ET) [...] takes an actual simple or complex schema type AT http://www.w3.org/TR/xpath20/ . [XQuery 1.0] XQuery 1.0:and an XML Query Language , D. Chamberlinexpected simple or complex schema type ET, A. Berglund, S. Boag, et. al., Editors. W3C Recommendation 23 Jan 2007. This versionand either returns a boolean value or raises [an error].

Document order (derived from [XDM], section 2.4)
A default namespace that applies to unprefixeddocument order is defined among all the element names; these declarations are scoped byinformation items that describe a given XML document. Document order is a total ordering. Informally, document order is the elements onorder in which theynodes appear so that different bindings may applyin different partsthe XML serialization 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 namesfn:data (from [ XDM ]) Editor's Note: ThisXFO], section reproduces the text2.4)
fn:data takes a sequence of Section 3.3.1.1. Elementitems and Attribute Node Type Names in [ XDM ], forreturns a sequence of atomic values.
The reader's convenience. Notice that, forresult of fn:data is the purposesequence of this specification,atomic values produced by applying the type namefollowing rules to each argument:

fn:string (from [XFO], section 2.3)
fn:string returns the value of its arguments represented as a xs:string. If no argument is supplied, the [context item]XP is used as the default argument. The behavior of the function if the argument is omitted is exactly the same as if the [context item]XP had been passed as the argument.
If the [context item]XP is undefined, an error is raised.
If the list of arguments is the empty sequence, the zero-length string is returned.
If the argument is a node, the function returns the [string-value]XDM of the node.
If the argument is an atomic value, then the function returns the value of the argument cast as a xs:string.

Governing type definition (from [XSD 1.1 Part 1], section 3.2.4.2 for an attribute, section 3.3.4.6 for an element)
The [validation attempted] property does not exist or is "none". Notation: Some aspects ofgoverning type assignment rely on the ability to access propertiesdefinition of the schema components. Such properties are indicated by the style {component property}. Note that this does not meanan attribute, in a lightweight schema processor cannot be used, it only means thatgiven schema-validity ·assessment· episode, is the application must have some mechanism to access{type definition} of the necessary properties.·governing attribute declaration·, unless the preciseprocessor has stipulated another type definition at the start of ·assessment· (see Assessing Schema-Validity (§5.2)), in which case it is the schemastipulated type definition.
The governing type definition of an element or attributeinformation item depends on the properties of the PSVI.E, in the PSVI, [Schema Part 1] definesa [type definition] property as well asgiven schema-validity ·assessment· episode, is the [type definition namespace], [type definition name] and [type definition anonymous] properties, which are effectively short-cut terms for propertiesfirst of the following which applies:
  1. An ·instance-specified 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 indefinition· which ·overrides· a type definition stipulated by the PSVI forprocessor (see Assessing Schema-Validity (§5.2)).
  2. A type definition stipulated by the element or attribute instance fromprocessor (see Assessing Schema-Validity (§5.2)).
  3. An ·instance-specified type definition· which ·overrides· the [type definition] associated with·selected type definition· of E.
  4. The declaration,·selected type definition· of E.
  5. The formervalue ·absent· if E is referred to below as the actual·skipped·.
  6. An ·instance-specified type anddefinition· which ·overrides· the latter as·locally declared type·.
  7. The ·locally declared type·.
  8. An ·instance-specified type definition·.
If none of these apply, there is no ·governing type definition· (or, in equivalent words, it is ·absent·).


In-scope schema definitions (from [XPath 2.0], section 2.1.1)
This is a generic term for all the element ordeclarations, attribute instance in question. Thedeclarations, and schema type depends ondefinitions that are in scope during processing of an expression.] It includes [the In-scope schema types, the declared type,In-scope element declarations, the actual type,substitution groups and the [validity] and [validation attempted] propertiesIn-scope attribute declarations].


Node (from [XDM], section 2.1)
(from [XDM], section 2.1) There are seven kinds of Nodes in the PSVI. If: The [validity]data model: document, element, attribute, text, namespace, processing instruction, and [validation attempted] properties existcomment.
(from [XPath 2.0], section 2) Each node has a unique node identity, a typed value, and a string value. In addition, some nodes have a name. The values "valid" and "full", respectively,typed value of a node is a sequence of zero or more atomic values. The schemastring value of a node is a value of type xs:string. The name of a node is a value of type xs:QName.

Normalized value (from [XSD 1.1 Part 1], section 3.1.4)
The normalized value of an element or attribute information item is represented byan expanded-QName whose namespace and local name correspondinitial value which has been normalized according to the first applicable items in the following list: Ifvalue of the declared type exists and is a unionwhiteSpace facet, and the actual type is (not the same asvalues of any other pre-lexical facets, associated with the declared type, and not asimple type derived from the declared type, but) one ofdefinition used in its validation.
The member typesinitial value of an attribute information item is the union, or derived from one of its member types: Ifnormalized attribute value, as specified in [XML], section 3.3.3 (Attribute-value normalization). Similarly, the {name} propertyinitial value of the declared typean element information item is present:the {target namespace} and {name} propertiesstring composed of, in document order, the character code of each character information item in the declared type.[children]info of that element information item.

Schema normalized value (from [XSD 1.1 Part 1], section 3.2.5.4 for attributes, section 3.3.5.4 for elements)
If an attribute's normalized value is valid with respect to the {name} property of the declaredgoverning type is absent:definition, then the namespace and local nameschema normalized value of the anonymous type name supplied forattribute is the declared type.normalized value as validated, otherwise it is absent.
If therean element information item is no declared type,not nilled and either the actualgoverning type definition is a union, then: Ifsimple type definition or its {content type} has {variety} simple, then the {name} propertyschema normalized value of the actual typeelement is present:the {target namespace} and {name} propertieslexical form of the actual type.its value constraint if applicable; else, if the {name} property ofelement's initial value is valid with respect to the actualsimple type definition as defined by String Valid ([XSD 1.1 Part 1], section 3.16.4), then the schema normalized value is absent:the namespace and local namenormalized value of the anonymous type name supplied for the actual type. Otherwise: If [type definition anonymous]item as validated; otherwise it is absent.

Statically-known namespaces (from [XPath 2.0], section 2.1.1)
This is false:a set of (prefix, URI) pairs that define all the {target namespace} and {name} propertiesnamespaces that are known during static processing of a given expression.

String value
The actual type. If [type definition anonymous]string value of a node is true:a string and can be extracted by applying the namespacefn:string function to the node.
(from [XDM], section 3.3.1.3) Element and local name ofattribute nodes have both typed-value and string-value properties. However, implementations are allowed some flexibility in how these properties are stored. An implementation may choose to store the anonymous type name supplied forstring-value only and derive the actual type.typed-value from it, or to store the [validity] property existstyped-value only and is "invalid",derive the string-value from it, or to store both the [validation attempted] property existsstring-value and is "partial",the schema typetyped-value.
In order to permit these various implementation strategies, some variations in the string value of an element is xs:anyType anda node are defined as insignificant. Implementations that store only the typetyped value of an attributea node are permitted to return a string value that is xs:anySimpleType.different from the [validity] property exists and is "notKnown", andoriginal lexical form of the [validation attempted] property exists and is "none",node content.

type-axis() (from [XSD-CD], section 4.4.5)
The schematype of an element is xs:untypedaxis contains simple type definition and thecomplex type of an attribute is xs:untypedAtomic.definition components linked to the [validity]current component through {type definition}, {type definitions}, {content type}, or [validation attempted] properties do not exist, the schema{simple type of an element is xs:untyped anddefinition} arcs

Typed value
The typetyped value of an attributea node is xs:untypedAtomic.a sequence of atomic values and can be extracted by applying the prefix associated withfn:data function to the type names is implementation-dependent. 9.2 Typed value determinationnode.
(from [XDM ])], section 3.3.1.2) 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 properly 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 126 Appendix E:B: Change Log (non-normative)

Since the WD published 22 June 2010: