SIMPLE WG                                                     M. Thomson
Internet-Draft                                                    Andrew
Expires: June 16, 2006                                 December 13, 2005


           A Document Format for Expressing XML Support (EXS)
           draft-thomson-simple-expressing-xml-support-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 16, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document defines a simple XML format for expressing support for,
   or understanding of sections of XML documents.  This format is
   designed for use in negotiating a common level of support in
   protocols.  XPath expressions are used to define which XML nodes
   within any particular instance document are understood.







Thomson                   Expires June 16, 2006                 [Page 1]


Internet-Draft           Expressing XML Support            December 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  5
   3.  Feature Model  . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Document Format  . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Establishing a Common Schema Definition  . . . . . . . . .  7
     4.2.  Indicating Support for an Entire Namespace . . . . . . . .  8
       4.2.1.  Specifying Schema Definitions for Namespaces . . . . .  8
     4.3.  Indicating Support for Individual Nodes  . . . . . . . . .  9
       4.3.1.  Excluding Node Descendants . . . . . . . . . . . . . .  9
     4.4.  Establishing Contexts  . . . . . . . . . . . . . . . . . . 10
     4.5.  Excluding Specific Nodes . . . . . . . . . . . . . . . . . 11
     4.6.  Excluded Node Types  . . . . . . . . . . . . . . . . . . . 11
   5.  Simplified XPath Profile . . . . . . . . . . . . . . . . . . . 13
     5.1.  Grammar  . . . . . . . . . . . . . . . . . . . . . . . . . 13
     5.2.  Limitations  . . . . . . . . . . . . . . . . . . . . . . . 14
   6.  Testing for Support  . . . . . . . . . . . . . . . . . . . . . 15
   7.  Expression of XML Support Schema . . . . . . . . . . . . . . . 16
   8.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
     10.1. MIME Type registration . . . . . . . . . . . . . . . . . . 22
     10.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 23
     10.3. XML Schema Registration  . . . . . . . . . . . . . . . . . 23
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
     11.2. Informative References . . . . . . . . . . . . . . . . . . 24
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 25
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
   Intellectual Property and Copyright Statements . . . . . . . . . . 27




















Thomson                   Expires June 16, 2006                 [Page 2]


Internet-Draft           Expressing XML Support            December 2005


1.  Introduction

   Extensible Markup Language (XML) documents are widely used to express
   data of all forms.  One highly desirable feature of XML is that
   documents are extensible, that is, additional functionality can be
   added to a base document.  For specifications, extensibility enables
   a basic specification to address an existing need without
   constraining the future use of the document and its future usage.
   Similarly, a specification can define a framework upon which other
   specifications may build solutions through extensibility, for example
   [I-D.ietf-geopriv-common-policy].

   Extensibility therefore offers a great deal of flexibility in
   specification.  However, extensibility can lead to arbitrary levels
   of complexity, which could lead to interoperability issues.  A
   document created by one system can only be understood in its entirety
   by another if the target system supports all the features used in the
   document.  In extreme cases, if a single fragment is not understood,
   the entire document could be unusable.

   To address this problem, interoperating systems need a method for
   negotiating a common level of support.  Negotiating support for
   entire document formats can already be accomplished through the use
   of MIME and protocol headers, such as the "Accept" header in HTTP and
   SIP.  However, a MIME type alone cannot express the rich set of
   features that could be combined within an XML document, nor do MIME
   types allow for expressing support for parts of a document.

   This document defines an expression of XML support (EXS) document
   format.  An EXS document is created so that document generators can
   determine if a generated document can be understood.  An EXS document
   is an XML document that specifies what features are understood by a
   particular processor.

   An EXS document can also be used to indicate to individual users the
   level of service that they are permitted to access.  This goes beyond
   an expression about what a service can provide and provides
   information on user permission.

   EXS is based on the XPath grammar [W3C.REC-xpath-19991116], which is
   a very rich and flexible tool for selecting XML nodes.  In order to
   simplify implementation, this document also defines a basic profile
   of XPath that removes predicates and limits the axes that may be
   used.

   This document does not define methods for sharing or publishing EXS
   documents.  Different applications and protocols are responsible for
   defining how this information is shared and any negotiation



Thomson                   Expires June 16, 2006                 [Page 3]


Internet-Draft           Expressing XML Support            December 2005


   completed.


















































Thomson                   Expires June 16, 2006                 [Page 4]


Internet-Draft           Expressing XML Support            December 2005


2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   Terminology from the XPath specification [W3C.REC-xpath-19991116] is
   used extensively in this document.  This includes the following
   terms: document, node, node-set, part, child, parent, descendant,
   axis, document order.









































Thomson                   Expires June 16, 2006                 [Page 5]


Internet-Draft           Expressing XML Support            December 2005


3.  Feature Model

   XML documents model data of varying complexity.  A _feature_ is an
   abstraction that refers to the capacity of a document to convey a
   particular unit of data.

   Since the concept of a feature is abstract, they are not necessarily
   discrete; that is, features can compose other features or overlap
   with other features.  For example, an element and its children could
   be characterized as a single feature; or each child element could
   each be characterized as a single feature; alternatively, a feature
   could also be a collection of attributes distributed throughout a
   document.

   This document defines a simplified feature model where individual
   features can be reduced to a node-set.  A feature is expressed as a
   single node or node-set.  Typically, this a set of elements,
   attributes and text nodes.  This model is chosen because the nature
   of XML is such that elements and attributes are the usual points
   where extensibility is used.

   The simple model presented in this document is not intended to be
   exhaustively capable of specifying capabilities.  The degree to which
   this model is applicable depends on the application and the subset of
   XPath that is used.


























Thomson                   Expires June 16, 2006                 [Page 6]


Internet-Draft           Expressing XML Support            December 2005


4.  Document Format

   An expression of XML support is made so that document generators can
   determine if a generated document can be understood.  An EXS document
   is intended to be evaluated against a target document.

4.1.  Establishing a Common Schema Definition

   The EXS document format described in the following sections relies on
   having a shared definition of XML document structure.  This is
   achieved primarily through the use of XML Schema definitions
   [W3C.REC-xmlschema-1-20041028], although other schema definition
   languages MAY be used.

   A shared schema definition cannot be guaranteed by using the
   namespace URI only.  It is uncommon to have different schema
   definitions sharing a namespace, therefore the schema definitions MAY
   be omitted from an EXS document.  However, the namespace alone cannot
   be used to ensure a shared schema definition.  Aside from the case
   where two applications have different schema definitions, XML Schema
   defines a "redefine" element that can be used to alter the
   definitions for particular schema.

   The "structure" element contains arbitrary content that is used to
   define the schema used in the document.  It is RECOMMENDED that this
   section is included and that it contain a "schema" element from
   [W3C.REC-xmlschema-1-20041028] that imports all necessary schema
   documents.

   Alternatively a common schema definition MAY be indicated through the
   use of the "ns" attribute on the "namespace" element.  This is
   described in more detail in Section 4.2.

   Schemas that are referenced by an EXS document and not included
   directly within the "structure" element SHOULD be retrieved, even if
   the schema for the given namespace is already known.

   For example, the following EXS fragment defines document structure by
   referencing an external schema document.

       <structure>
         <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
           <xs:import namespace="http://example.com/ns/app"
                schemaLocation="http://example.com/schema/app.xsd"/>
         </xs:schema>
       </structure>

   Note that schema definitions for published RFCs are not usually



Thomson                   Expires June 16, 2006                 [Page 7]


Internet-Draft           Expressing XML Support            December 2005


   published to a fixed location.  For these schema, it is not necessary
   to provide a schema definition, providing that the schema from the
   published RFC is used.  Schema URNs that are registered with IANA
   SHOULD NOT be used in place of URLs.

4.2.  Indicating Support for an Entire Namespace

   Support for all nodes from a namespace is indicated by using the
   "namespace" element.  The namespace is indicated by the "ns"
   attribute.  This statement indicates that all nodes that belong to
   given namespace are supported.

   From the perspective of the XPath data model, a node is supported if
   the namespace URI in the expanded-name of the node matches the value
   of the namespace.

   For example, the following minimal EXS document that indicates
   support for an entire namespace:

     <?xml version="1.0"?>
     <supported-xml xmlns="urn:ietf:params:xml:ns:exs">
       <namespace ns="http://example.com/ns/app"/>
     </supported-xml>

   The XPath data model states that attributes with no prefix do not
   have a namespace URI in their expanded name.  Similarly, text nodes
   do not have an expanded name.  For the purposes of testing for
   support, all text children and attribute children that have no
   namespace prefix belong to the same namespace as their parent
   element.

   For example, when the following document is evaluated against the
   above statement, this selects the "yes:supported" element and its
   text content, the "param" attribute and the "yes:info" attribute.

       <yes:supported xmlns:yes="http://example.com/ns/app"
                  xmlns:no="http://example.com/ns/other"
                  param="yes" no:extra="no">
         text content <no:not-supported yes:info="value"/>
       </supported>

   This document format SHOULD only be used where namespaces in XML are
   employed.

4.2.1.  Specifying Schema Definitions for Namespaces

   The "namespace" element also allows for references to schema
   definitions, which may be used in place of the "structure" element.



Thomson                   Expires June 16, 2006                 [Page 8]


Internet-Draft           Expressing XML Support            December 2005


   The "schemaLocation" attribute indicates the location of the schema
   definition for the given namespace.  It is RECOMMENDED that this
   attribute be included where possible to avoid any potential
   miscommunication.

   A "namespace" element MAY occur with the same namespace multiple
   times within an EXS document, however the value of the
   "schemaLocation" attribute MUST not have multiple different values
   within the same document.  An omitted "schemaLocation" attribute
   indicates that the value is the same as an included "schemaLocation"
   attribute for the same namespace.

   Schema definitions MAY be included in the document through the use of
   the "structure" element.  In this case, the "schemaLocation"
   attribute SHOULD be omitted, or it should contain a fragment URI
   referring to the schema definition.

   The following EXS fragment refers to the location of the schema for a
   supported namespace:

       <namespace ns="http://example.com/ns/app"
                  schemaLocation="http://example.com/schema/app.xsd"/>

4.3.  Indicating Support for Individual Nodes

   Support for individual nodes is indicated by using the "node"
   element.  The "path" attribute of this element includes an XPath
   expression that selects a node-set from the target document.

   For example, the following EXS document indicates that the entirety
   of the "app:supported" element is supported as a child of the current
   context:

       <node xmlns:app="http://www.example.com/ns/app"
             path="app:supported"/>

   Node expressions are evaluated in the current context, see
   Section 4.4 for details.  If the "app:supported" element is suported
   in all contexts, then a value of "//app:supported" might be a better
   expression.

4.3.1.  Excluding Node Descendants

   Unless otherwise specified, selecting a node using the "node" element
   also selects all of its descendants.  The "descendants" attribute
   specifies the types of descendants are included.  The value is a list
   that MAY include any of the following values: "elements" (element
   descendants are included), "attributes" (attribute descendants are



Thomson                   Expires June 16, 2006                 [Page 9]


Internet-Draft           Expressing XML Support            December 2005


   included) and "text" (text descendants are included).  Unless the
   value "elements" is included, only the immediate child attribute and
   text nodes are included.

   Two special values are also defined for convenience: "##all"
   indicates that all descendants are included, and "##none" indicates
   that no descendants are included. "##all" is the default value, which
   is equivalent to "elements attributes text".

   For example, the following EXS document indicates that the entirety
   of the "app:supported" element and its attributes is understood.
   Text and element descendants of these nodes are not supported.

       <node xmlns:app="http://www.example.com/ns/app"
             path="app:supported" descendants="attributes"/>

   The "descendants" attribute is particularly useful when an element
   could contain any content.  For instance, this is allowed by the
   "any" or "anyAttribute" in XML Schema [W3C.REC-xmlschema-1-20041028].

       <!-- bad example -->
       <node xmlns:cp="urn:ietf:params:xml:ns:common-policy"
             path="cp:ruleset"/>

   Since the content model of the "ruleset" element (through its
   descendants, see [I-D.ietf-geopriv-common-policy]) could include
   arbitrary content, this statement constitutes an unlimited promise of
   support.  Where any content is allowed, this expression is NOT
   RECOMMENDED, instead it SHOULD be limited by using the "descendants"
   attribute.

4.4.  Establishing Contexts

   For the purposes of simplification of grouping the "context" enables
   the selection of a document subset.  The "path" attribute of this
   element is an XPath expression that selects a node-set.  Elements
   that are nested within the "context" element are evaluated once for
   each node in the context node-set.

   Contexts MAY be nested within other contexts, in which case the path
   expression for the context is evaluated within the context of each
   node of the enclosing context node-set.

   Within a context, a "namespace" element can only select descendants
   of the context node, including the context node itself.  Note that a
   "node" element can select any node from the document, however it is
   RECOMMENDED that nodes are only selected from the descendants of the
   context node.



Thomson                   Expires June 16, 2006                [Page 10]


Internet-Draft           Expressing XML Support            December 2005


   Since the "context" element selects a node-set that could contain any
   number of nodes, it is RECOMMENDED that the node-set is restricted
   sufficiently to limit the performance impact of evaluating nested
   statements.  If nested "context" statements are used, it is
   RECOMMENDED that the node-set be restricted to a single node.

   For example, the following EXS document indicates that the
   "http://example.com/ns/app" namespace is understood within the
   "enclosing" element only.

       <context xmlns:enc="http://example.com/ns/enclosing
           path="//enc:enclosing">
         <namespace ns="http://example.com/ns/app"/>
       </context>

4.5.  Excluding Specific Nodes

   The "except" element MAY be included as a child of either the
   "namespace" or "node" elements to indicate nodes that are excluded.

   Similar to "node", the "except" element selects all descendants
   unless the "descendants" attribute is used.

   When nested with a "node" element, the "except" element is evaluated
   as if the "node" element had established a context.  That is.

   For example, the following EXS fragment indicates support for the
   "app:supported" element and all its contents, except for the
   "app:exception" element (when it is a child of "app:supported").

       <node xmlns:app="http://www.example.com/ns/app"
             path="app:supported">
         <except path="app:exception"/>
       </node>

4.6.  Excluded Node Types

   The EXS document format is aimed at the three primary XML node types:
   elements, attributes and text.  Support for other node types is
   limited.

   Namespace prefix declarations ("xmlns" attributes) MUST always be
   supported, regardless of any statements to the contrary. "except"
   elements MUST NOT select namespace prefix declarations.

   Comment nodes SHOULD NOT be the subject of expressions of support.
   Declarations that indicate support for comments SHOULD be ignored.
   Note however, that comment nodes affect the XPath content model,



Thomson                   Expires June 16, 2006                [Page 11]


Internet-Draft           Expressing XML Support            December 2005


   specifically text nodes; therefore, where text nodes are selected,
   expressions might need to compensate for comment nodes.

   Processing instructions SHOULD automatically be considered as
   unsupported.














































Thomson                   Expires June 16, 2006                [Page 12]


Internet-Draft           Expressing XML Support            December 2005


5.  Simplified XPath Profile

   This section defines a simplified profile of XPath that MAY be
   required by protocols.  This profile retains only the parts of the
   XPath grammar that enable the selection of elements and attributes.

   Protocols MAY use this profile, or define any other profile that most
   suits the application.  However, protocols that use this
   specification MUST specify which XPath profile is required.

5.1.  Grammar

   This profile defines a simple XPath grammar that prohibits the use of
   axes, except for the special axes "child", "self",
   "descendent-or-self" and "attribute".  These axes MUST be specified
   using their abbreviated syntax only; they cannot be used with the
   double-colon ("::") notation.  Note that the parent axis ("..") is
   not allowed by this profile.

   Predicates are excluded from this grammar, as are operators and all
   functions except the "node()" and "text()" functions.  This grammar
   excludes support for selecting comments and processing instructions.

   The following ABNF grammar [RFC4234] describes this XPath profile.

     LocationPath         = RelativeLocationPath / AbsoluteLocationPath
     AbsoluteLocationPath = "/" RelativeLocationPath?
                            / AbbreviatedAbsoluteLocationPath
     RelativeLocationPath = Step / (RelativeLocationPath "/" Step)
                            / AbbreviatedRelativeLocationPath
     Step                 = NodeTest / AbbreviatedStep
     NodeTest             = ([AttributeSpecifier] NameTest)
                            / (NodeType "()")
     AbbreviatedAbsoluteLocationPath = "//" RelativeLocationPath
     AbbreviatedRelativeLocationPath = RelativeLocationPath "//" Step
     AbbreviatedStep      = "." / ".."
     AttributeSpecifier   = "@"
     NameTest             = "*" / (NCName ":*") / QName
     NodeType             = %x74.65.78.74 / %x6E.6F.64.65
                            ; case-sensitive: "text" / "node"

   Definitions for "NCName" and "QName" can be found in [W3C.REC-xml-
   20040204].

   These restrictions reduce the complexity of a processor and mean that
   a processor only needs to provide support for node-set results.
   Since the included axes are all evaluated in document order and no
   predicates are allowed, this profile also grants significant scope



Thomson                   Expires June 16, 2006                [Page 13]


Internet-Draft           Expressing XML Support            December 2005


   for optimization.

5.2.  Limitations

   In order to use this simplified XPath profile, features MUST be able
   to be described as a set of elements and attributes only.

   This simplified XPath profile is limited in its capability to deal
   with loosely structured documents.  In terms of expressing the
   context where a node is supported, this grammar only allows the
   parents of a node to be indicated.  For instance, indicating support
   for an element that is dependent on the value of an attribute
   requires the use of predicates.






































Thomson                   Expires June 16, 2006                [Page 14]


Internet-Draft           Expressing XML Support            December 2005


6.  Testing for Support

   An application can test if a document that it generates conforms to a
   particular EXS document by applying the following procedure:

   1.  Search for the context node-set.  The initial node set consists
       of the document root (the parent of the document element) only.

   2.  For each node in that node-set:

       A.  Find all "namespace" and "node" elements within the current
           context.

       B.  Conditionally mark the nodes that match the each statement:

           +  For the "namespace" element, this includes all nodes that
              are in the current context and the specified namespace.
              All direct descendants of these nodes that are either
              attributes with the null namespace or text nodes are also
              included.

           +  For the "node" element, this includes all nodes in the
              node-set specified.  All descendants of those nodes are
              also marked based on the value of the "descendants"
              attribute.

       C.  If the support statement has "except" children, evaluate each
           and remove any conditional marks from the node-set result.
           Similar to the "node" element, descendants of excluded nodes
           are also excluded based on the value of the "descendants"
           attribute.

       D.  Mark all remaining conditionally marked nodes as supported.

       E.  Find all "context" element children of the current context
           node.

       F.  Recurse: evaluate step 1. for each context child.

   3.  Mark all namespace prefix declarations and comments as supported.

   4.  If any nodes are not marked, the document is considered as not
       supported and this procedure terminates.

   5.  The document is validated against the specified schema, taking
       into account any schemas that are indicated.  Only valid
       documents are considered supported.




Thomson                   Expires June 16, 2006                [Page 15]


Internet-Draft           Expressing XML Support            December 2005


7.  Expression of XML Support Schema

   <?xml version="1.0"?>
   <xs:schema
       targetNamespace="urn:ietf:params:xml:ns:exs"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       xmlns:exs="urn:ietf:params:xml:ns:exs"
       elementFormDefault="qualified"
       attributeFormDefault="unqualified">

     <xs:element name="supported-xml" type="exs:exsBaseType"/>
     <xs:complexType name="exsBaseType">
       <xs:complexContent>
         <xs:restriction base="xs:anyType">
         <xs:sequence>
           <xs:element ref="exs:structure" minOccurs="0"/>
           <xs:element ref="exs:namespace"
                       minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="exs:node"
                       minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="exs:context"
                       minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         </xs:restriction>
       </xs:complexContent>
     </xs:complexType>

     <xs:element name="structure" type="exs:structureType"/>
     <xs:complexType name="structureType">
       <xs:complexContent>
         <xs:restriction base="xs:anyType">
           <xs:any namespace="##other" parseContents="strict"
                   minOccurs="0" maxOccurs="unbounded"/>
         </xs:restriction>
       </xs:complexContent>
     </xs:complexType>

     <xs:element name="context" type="exs:contentType"/>
     <xs:complexType name="contentType">
       <xs:complexContent>
         <xs:extension base="exs:exsBaseType">
           <xs:attribute name="path" type="exs:xpathType"
                         use="required"/>
         </xs:extension>
       </xs:complexContent>
     </xs:complexType>

     <xs:complexType name="supportedBaseType">



Thomson                   Expires June 16, 2006                [Page 16]


Internet-Draft           Expressing XML Support            December 2005


       <xs:complexContent>
         <xs:restriction base="xs:anyType">
           <xs:sequence>
             <xs:element ref="exs:except"
                         minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
         </xs:restriction>
       </xs:complexContent>
     </xs:complexType>

     <xs:element name="namespace" type="exs:namespaceType"/>
     <xs:complexType name="namespaceType">
       <xs:complexContent>
         <xs:extension base="exs:supportedBaseType">
           <xs:attribute name="ns" type="xs:anyURI"
                         use="required"/>
           <xs:attribute name="schemaLocation" type="xs:anyURI"
                         use="optional"/>
         </xs:extension>
       </xs:complexContent>
     </xs:complexType>

     <xs:attributeGroup name="nodeSelectGroup">
       <xs:attribute name="path" type="exs:xpathType"
                     use="required"/>
       <xs:attribute name="descendants" type="exs:descendantsType"
                     use="optional"/>
     </xs:attributeGroup>

     <xs:simpleType name="descendantsType">
       <xs:list>
         <xs:simpleType>
           <xs:restriction base="xs:token">
             <xs:enumeration value="elements"/>
             <xs:enumeration value="attributes"/>
             <xs:enumeration value="text"/>
             <xs:enumeration value="##all"/>
             <xs:enumeration value="##none"/>
           </xs:restriction>
         </xs:simpleType>
       </xs:list>
     </xs:simpleType>

     <xs:element name="node" type="exs:nodeType"/>
     <xs:complexType name="nodeType">
       <xs:complexContent>
         <xs:extension base="exs:supportedBaseType">
           <xs:attributeGroup ref="exs:nodeSelectGroup"/>



Thomson                   Expires June 16, 2006                [Page 17]


Internet-Draft           Expressing XML Support            December 2005


         </xs:extension>
       </xs:complexContent>
     </xs:complexType>

     <xs:element name="except" type="exs:exceptType"/>
     <xs:complexType name="exceptType">
       <xs:complexContent>
         <xs:restriction base="xs:anyType">
           <xs:attributeGroup ref="exs:nodeSelectGroup"/>
         </xs:restriction>
       </xs:complexContent>
     </xs:complexType>

     <xs:simpleType name="xpathType">
       <xs:restriction base="xs:token">
         <xs:pattern value="/{0,2}((((((ancestor|descendant)(-or-self)?
    |attribute|child|(following|preceding)(-sibling)?|namespace|parent
    |self)::|@)?(([a-zA-Z_][\w\.\-_]*:)?([a-zA-Z_][\w\.\-_]*|\*)
    |(comment|text|node)\(\)|processing-instruction\((&quot;[^&quot;]*
    &quot;|'[^']*')?\))(\[.*\])*)|\.{1,2})//?)*(((((ancestor|descendant)
    (-or-self)?|attribute|child|(following|preceding)(-sibling)?
    |namespace|parent|self)::|@)?(([a-zA-Z_][\w\.\-_]*:)?([a-zA-Z_]
    [\w\.\-_]*|\*)|(comment|text|node)\(\)|processing-instruction\(
    (&quot;[^&quot;]*&quot;|'[^']*')?\))(\[.*\])*)|\.{1,2})"/>
       </xs:restriction>
     </xs:simpleType>
   </xs:schema>

   For formatting purposes, the EXS schema contains extra line-breaks in
   the XPath pattern.  These must be removed to use this schema - the
   actual value does not contain spaces or newline characters.




















Thomson                   Expires June 16, 2006                [Page 18]


Internet-Draft           Expressing XML Support            December 2005


8.  Example

     <?xml version="1.0"?>
     <supported-xml xmlns="urn:ietf:params:xml:ns:exs"
                    xmlns:fw="http://example.com/ns/framework"
                    xmlns:app="http://example.com/ns/app"
                    xmlns:ext="http://example.com/ns/extension">

       <!-- define structure by importing app.xsd -->
       <structure>
         <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
            <xs:import namespace="http://example.com/ns/app"
                schemaLocation="http://example.com/schema/app.xsd"/>
        </xs:schema>
       </structure>

       <!-- declare support for all of the framework ns and
            provide a URL to its definition -->
       <namespace ns="http://example.com/ns/framework"
          schemaLocation="http://example.com/schema/fw.xsd"/>

       <!-- establish a context to simplify the enclosed rules -->
       <context path="/fw:ruleset/fw:rule">

         <!-- the conditions child element -->
         <context path="fw:conditions">

           <!-- the entire app ns is understood in this context,
                except the civic-loc-condition element and anything with
                a crsName attribute of urn:ogc:def:crs:EPSG:6.6:4326 -->
           <namespace ns="http://example.com/ns/app">
             <except path="app:civic-loc-condition"/>
             <except path="//@crsName[string(.)!=
                               'urn:ogc:def:crs:EPSG:6.6:4326']"/>
           </namespace>

           <!-- the ext:happy element at any depth -->
           <node path="//ext:happy"/>
         </context>

         <!-- the actions element,
              which is a descendant of the context node -->
         <context path=".//fw:actions">
           <node path="ext:log"/>
         </context>

         <!-- the actions element -->
         <context path="fw:transformations">



Thomson                   Expires June 16, 2006                [Page 19]


Internet-Draft           Expressing XML Support            December 2005


           <!-- The app ns within this context,
                except the civic-loc-transformation element -->
           <namespace ns="http://example.com/ns/app">
             <except path="app:civic-loc-transformation"/>
           </namespace>

           <!-- the min-security element and its attribute and
                text children, excluding any descendant elements -->
           <node path="ext:min-security" descendants="attributes text"/>
         </context>
       </context>
     </supported-xml>







































Thomson                   Expires June 16, 2006                [Page 20]


Internet-Draft           Expressing XML Support            December 2005


9.  Security Considerations

   In general, the purpose for which EXS documents are used will
   determine what security constraints apply.  This section provides
   some guidance on the types of security considerations that SHOULD be
   made when using this specification.

   An expression of XML support document could reveal capability
   information about a service.  This information could be used for
   competitive analysis, or as input to an attack that focusses on
   unsupported values or border cases.  Where the EXS document is widely
   published, there are often many legitimate means for obtaining this
   sort of information, so encryption of this information is not
   especially important.

   EXS documents can be used to indicate the service level offered to a
   individual users of a service.  This information is sensitive to that
   user and therefore users SHOULD be authenticated and EXS documents
   SHOULD be encrypted where information applies to individuals users.

   If an EXS document is alterable, an attacker could use it to make
   promises of support that cannot be satisfied.  Conversely, a forged
   EXS could be used to limit the features used by a user.  Protocols
   that provide message integrity SHOULD be used to prevent alterations.
   Services that provide EXS documents out-of-band to protocols that use
   the information SHOULD be authenticated by their clients.

























Thomson                   Expires June 16, 2006                [Page 21]


Internet-Draft           Expressing XML Support            December 2005


10.  IANA Considerations

10.1.  MIME Type registration

   This specification requests the registration of a new MIME type
   according to the procedures of [RFC2048] and guidelines in [RFC3023].

      MIME media type name: application

      MIME subtype name: exs+xml

      Mandatory parameters: none

      Optional parameters: Same as charset parameter application/xml as
      specified in RFC 3023[RFC3023].

      Encoding considerations: Same as encoding considerations of
      application/xml as specified in RFC 3023 [RFC3023].

      Security considerations: See Section 10 of RFC 3023 [RFC3023] and
      Section 9 of RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace
      XXXX with the RFC number of this specification]].

      Interoperability considerations: none.

      Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR:
      Please replace XXXX with the RFC number of this specification]]

      Applications which use this media type: This document type is used
      to express application support for XML features within documents.
      This has general application for a range of applications.

      Additional Information:

         Magic Number: None

         File Extension: .exs

         Macintosh file type code: "TEXT"

         Personal and email address for further information: Martin
         Thomson, martin.thomson@andrew.com

         Intended usage: COMMON

         Author/Change controller: The IETF.





Thomson                   Expires June 16, 2006                [Page 22]


Internet-Draft           Expressing XML Support            December 2005


10.2.  URN Sub-Namespace Registration

   This section registers a new XML namespace,
   "urn:ietf:params:xml:ns:exs" as per the guidelines in [RFC3688].

      URI: urn:ietf:params:xml:ns:exs

      Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
      Martin Thomson (martin.thomson@andrew.com).

      XML:

         BEGIN
           <?xml version="1.0"?>
           <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
             "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
           <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
             <head>
               <title>Expression of XML Support</title>
             </head>
             <body>
               <h1>Namespace for Expression of XML Support</h1>
               <h2>urn:ietf:params:xml:ns:exs</h2>
   [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
       with the RFC number for this specification.]]
               <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
             </body>
           </html>
         END

10.3.  XML Schema Registration

   This section registers an XML schema as per the procedures in
   [RFC3688].

      URI: urn:ietf:params:xml:schema:exs

      Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
      Martin Thomson (martin.thomson@andrew.com).

      The XML for this schema can be found in Section 7 of this document
      between lines starting with "<?xml version" and "</schema>",
      inclusive.








Thomson                   Expires June 16, 2006                [Page 23]


Internet-Draft           Expressing XML Support            December 2005


11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

   [RFC2048]  Freed, N., Klensin, J., and J. Postel, "Multipurpose
              Internet Mail Extensions (MIME) Part Four: Registration
              Procedures", BCP 13, RFC 2048, November 1996.

   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
              Types", RFC 3023, January 2001.

   [W3C.REC-xpath-19991116]
              DeRose, S. and J. Clark, "XML Path Language (XPath)
              Version 1.0", W3C REC REC-xpath-19991116, November 1999.

   [W3C.REC-xml-20040204]
              Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T.,
              and E. Maler, "Extensible Markup Language (XML) 1.0 (Third
              Edition)", W3C REC REC-xml-20040204, February 2004.

11.2.  Informative References

   [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

   [I-D.ietf-geopriv-common-policy]
              Schulzrinne, H., "A Document Format for Expressing Privacy
              Preferences", draft-ietf-geopriv-common-policy-06 (work in
              progress), October 2005.

   [W3C.REC-xmlschema-1-20041028]
              Maloney, M., Beech, D., Thompson, H., and N. Mendelsohn,
              "XML Schema Part 1: Structures Second Edition", W3C
              REC REC-xmlschema-1-20041028, October 2004.











Thomson                   Expires June 16, 2006                [Page 24]


Internet-Draft           Expressing XML Support            December 2005


Appendix A.  Acknowledgements

   The author would like to recognize the work of Jonathon Rosenberg for
   his work in defining a document format for policy capabilities.
   Security considerations are largely based on that work.














































Thomson                   Expires June 16, 2006                [Page 25]


Internet-Draft           Expressing XML Support            December 2005


Author's Address

   Martin Thomson
   Andrew
   PO Box U40
   Wollongong University Campus, NSW  2500
   AU

   Phone: +61 2 4221 2915
   Email: martin.thomson@andrew.com
   URI:   http://www.andrew.com/








































Thomson                   Expires June 16, 2006                [Page 26]


Internet-Draft           Expressing XML Support            December 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Thomson                   Expires June 16, 2006                [Page 27]