4.4.1 The CanonicalizationMethod Element
CanonicalizationMethod is a required element that
specifies the canonicalization algorithm applied to the SignedInfo
element prior to performing signature calculations. This element uses
the general structure for algorithms described in Algorithm Identifiers and Implementation Requirements
(section 6.1). Implementations must support the required canonicalization algorithms.
Schema Definition:
<element name="CanonicalizationMethod" type="ds:CanonicalizationMethodType"/>
<complexType name="CanonicalizationMethodType" mixed="true">
<sequence>
<any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
<!-- (0,unbounded) elements from (1,1) namespace -->
</sequence>
<attribute name="Algorithm" type="anyURI" use="required"/>
</complexType>
In 2.0 mode the SignedInfo
element is presented as a single subtree with no exclusions to the
Canonicalization 2.0 algorithm. All the subelements of Canonicalization
are presented as parameters.
2.0 mode uses CanonicalizationMethod in more way - as a canonicalization for the Reference.
The rest of the section is only applicable for compatibility mode.
Alternatives to the required canonicalization
algorithms (section 6.5), such as Canonical
XML with Comments (section 6.5.1) or a minimal canonicalization
(such as CRLF and charset normalization)
, may be explicitly specified but are not required. Consequently, their
use may not interoperate with other applications that do not support
the specified algorithm (see XML
Canonicalization and Syntax Constraint Considerations, section 7).
Security issues may also arise in the treatment of entity processing
and comments if non-XML aware canonicalization algorithms are not
properly constrained (see section 8.1.2: Only What
is "Seen" Should be Signed).
The way in which the SignedInfo element is presented
to the canonicalization method is dependent on that method. The
following applies to algorithms which process XML as nodes or
characters:
- XML based canonicalization implementations must be provided with
an [XPATH] node-set originally formed from the document containing
the
SignedInfo and currently indicating the SignedInfo,
its descendants, and the attribute and namespace nodes of SignedInfo
and its descendant elements.
- Text based canonicalization algorithms (such as CRLF and charset
normalization) should be provided with the UTF-8 octets that represent
the well-formed
SignedInfo element, from the first
character to the last character of the XML representation, inclusive.
This includes the entire text of the start and end tags of the SignedInfo
element as well as all descendant markup
and character data (i.e., the text)
between those tags. Use of text based canonicalization of SignedInfo
is not recommended.
We recommend applications that implement a text-based instead of
XML-based canonicalization -- such as resource constrained apps --
generate canonicalized XML as their output serialization so as to
mitigate interoperability and security concerns. For instance, such an
implementation should (at least) generate standalone XML
instances [XML10].
NOTE: The signature
application must exercise great care in accepting and executing an
arbitrary CanonicalizationMethod. For example, the
canonicalization method could rewrite the URIs of the References
being validated. Or, the method could massively transform SignedInfo
so that validation would always succeed (i.e., converting it to a
trivial signature with a known key over trivial data). Since CanonicalizationMethod
is inside SignedInfo, in the resulting canonical form it
could erase itself from SignedInfo or modify the SignedInfo
element so that it appears that a different canonicalization function
was used! Thus a Signature which appears to authenticate
the desired data with the desired key, DigestMethod, and SignatureMethod,
can be meaningless if a capricious CanonicalizationMethod
is used.
4.4.3 The Reference Element
Reference is an element that may occur one or more
times. It specifies a digest algorithm and digest value, and optionally
an identifier of the object being signed, the type of the object,
and/or a list of transforms to be applied prior to digesting. The
identification (URI) and transforms describe how the digested content
(i.e., the input to the digest method) was created. The Type
attribute facilitates the processing of referenced data. For example,
while this specification makes no requirements over external data, an
application may wish to signal that the referent is a Manifest.
An optional ID attribute permits a Reference to be
referenced from elsewhere.
Schema Definition:
<element name="Reference" type="ds:ReferenceType"/>
<complexType name="ReferenceType">
<sequence>
<element ref="ds:Transforms" minOccurs="0"/>
<element ref="ds:DigestMethod"/>
<element ref="ds:DigestValue"/>
</sequence>
<attribute name="Id" type="ID" use="optional"/>
<attribute name="URI" type="anyURI" use="optional"/>
<attribute name="Type" type="anyURI" use="optional"/>
</complexType>
4.4.3.1 Signature Modes
The XML Signature 2.0 Specification is designed to support a new,
simplified processing model while remaining backwardly compatible with
the older 1.x processing model. These are termed "2.0 Mode" and
"Compatibility Mode"
respectively.
A generic signature processor can determine the mode of a signature
by examining the Reference element's attributes and the child
element(s) of the Transforms element. If the URI attributes is
present, "Compatibility Mode" is used. If the URI attributes
is not present, and the Transforms element contains
exactly one Transform element with an Algorithm of "http://www.w3.org/2010/xmldsig2#newTransformModel",
then "2.0 Mode"
is used. Otherwise, "Compatibility Mode" is used. All the references of
a signature
should have the same mode, i.e. they should all be in 2.0 mode, or all
be in Compatibility mode.
4.4.3.2 The URI Attribute for Reference in compatibility mode
The URI attribute must be omitted for "2.0 Mode" signatures. If the
attribute is omitted for a "Compatibility Mode" signature, then the
receiving application is expected to know the identity of the object.
For example, a lightweight data protocol
might omit this attribute given the identity of the object is part of
the application context.
In "Compatibility mode" at most one Reference element without a URI
attribute may be present
in any particular SignedInfo, or Manifest.
The remainder of this section applies only to "Compatibility Mode".
The URI attribute identifies a data object using a
URI-Reference [URI].
The mapping from this attribute's value to a URI reference must be
performed as specified in section 3.2.17 of [XMLSCHEMA-2].
Additionally: Some existing implementations are known to verify the
value of the URI attribute against the grammar in [URI]. It is
therefore safest to perform any necessary escaping while generating the
URI attribute.
We RECOMMEND XML Signature applications be able to dereference URIs
in the HTTP scheme. Dereferencing a URI in the HTTP scheme must comply
with the Status
Code Definitions of [HTTP11] (e.g., 302, 305 and 307 redirects
are followed to obtain the entity-body of a 200 status code response).
Applications should also be cognizant of the fact that protocol
parameter and state information, (such as HTTP cookies, HTML device
profiles or content negotiation), may affect the content yielded by
dereferencing a URI.
If a resource is identified by more than one URI, the most specific
should be used (e.g.
http://www.w3.org/2000/06/interop-pressrelease.html.en instead of
http://www.w3.org/2000/06/interop-pressrelease). (See the Reference Validation section (section
3.2.1) for further information on reference processing.)
If the URI attribute is omitted altogether, the
receiving application is expected to know the identity of the object.
For example, a lightweight data protocol might omit this attribute
given the identity of the object is part of the application context. In
Compatibility mode, this attribute may be omitted from at most one Reference
in any particular SignedInfo, or Manifest.
The optional Type attribute contains information about the type of
object being signed after all ds:Reference transforms
have been applied. This is represented as a URI. For example:
Type="http://www.w3.org/2000/09/xmldsig#Object"
Type="http://www.w3.org/2000/09/xmldsig#Manifest"
The Type attribute applies to the item being pointed
at, not its contents. For example, a reference that results in the
digesting of an Object element containing a SignatureProperties
element is still of type #Object. The Type
attribute is advisory. No validation of the type information is
required by this specification.
4.4.3.3 The "Compatibility Mode" Reference Processing Model
The data-type of the result of URI dereferencing or subsequent
Transforms is either an octet stream or an XPath node-set.
The Transforms specified in this document are defined
with respect to the input they require. The following is the default
signature application behavior:
- If the data object is an octet stream and the next transform
requires a node-set, the signature application must attempt to parse
the octets yielding the required node-set via [XML10] well-formed
processing.
- If the data object is a node-set and the next transform requires
octets, the signature application must attempt to convert the node-set
to an octet stream using Canonical XML [XML-C14N].
Users may specify alternative transforms that override these
defaults in transitions between transforms that expect different
inputs. The final octet stream contains the data octets being secured.
The digest algorithm specified by DigestMethod is then
applied to these data octets, resulting in the DigestValue.
Note: The Reference
Generation Model (section 3.1.1) includes further restrictions on
the reliance upon defined default transformations when applications
generate signatures.
In this specification, a 'same-document' reference is defined as a
URI-Reference that consists of a hash sign ('#') followed by a fragment
or alternatively consists of an empty URI [URI].
Unless the URI-Reference is such a 'same-document' reference , the
result of dereferencing the URI-Reference must be an octet stream. In
particular, an XML document identified by URI is not parsed by the
signature application unless the URI is a same-document reference or
unless a transform that requires XML parsing is applied. (See Transforms (section 4.4.3.4).)
When a fragment is preceded by an absolute or relative URI in the
URI-Reference, the meaning of the fragment is defined by the resource's
MIME type [RFC2045]. Even for XML documents, URI dereferencing
(including the fragment processing) might be done for the signature
application by a proxy. Therefore, reference validation might fail if
fragment processing is not performed in a standard way (as defined in
the following section for same-document references). Consequently, we
RECOMMEND in this case that the URI attribute not
include fragment identifiers and that such processing be specified as
an additional XPath Transform or XPath Filter
2 Transform [XMLDSIG-XPATH-FILTER2].
When a fragment is not preceded by a URI in the URI-Reference, XML
Signature applications must support the null URI and shortname XPointer
[XPTR-FRAMEWORK]. We RECOMMEND support for the same-document
XPointers '#xpointer(/)' and '#xpointer(id('ID'))'
if the application also intends to support any canonicalization that preserves comments. (Otherwise URI="#foo"
will automatically remove comments before the canonicalization can even
be invoked due to the processing defined in Same-Document URI-References
(section 4.4.3.3).) All other support for XPointers is optional,
especially all support for shortname and other XPointers in external
resources since the application may not have control over how the
fragment is generated (leading to interoperability problems and
validation failures).
'#xpointer(/)' must be interpreted to identify the root
node [XPATH] of the document that contains the URI
attribute.
'#xpointer(id('ID'))' must be interpreted to
identify the element node identified by '#element(ID)'
[XPTR-ELEMENT] when evaluated with respect to the document that
contains the URI attribute.
The original edition of this specification [XMLDSIG-CORE]
referenced the XPointer Candidate Recommendation
[XPTR-XPOINTER-CR2001] and some implementations support it
optionally. That Candidate Recommendation has been superseded by the
[XPTR-FRAMEWORK], [XPTR-XMLNS] and [XPTR-ELEMENT]
Recommendations, and -- at the time of this edition -- the
[XPTR-XPOINTER] Working Draft. Therefore, the use of the
xpointer() scheme [XPTR-XPOINTER] beyond the usage discussed
in this section is discouraged.
The following examples demonstrate what the URI attribute identifies
and how it is dereferenced:
URI="http://example.com/bar.xml"- Identifies the octets that represent the external resource
'http://example.com/bar.xml', that is probably an XML document given
its file extension.
URI="http://example.com/bar.xml#chapter1"- Identifies the element with ID attribute value 'chapter1' of the
external XML resource 'http://example.com/bar.xml', provided as an
octet stream. Again, for the sake of interoperability, the element
identified as 'chapter1' should be obtained using an XPath transform
rather than a URI fragment (shortname XPointer resolution in external
resources is not required in this specification).
URI=""- Identifies the node-set (minus any comment nodes) of the XML
resource containing the signature
URI="#chapter1"- Identifies a node-set containing the element with ID attribute
value 'chapter1' of the XML resource containing the signature. XML
Signature (and its applications) modify this node-set to include the
element plus all descendants including namespaces and attributes -- but
not comments.
4.4.3.4 "Compatibility Mode" Same-Document URI-References
Dereferencing a same-document reference must result in an XPath
node-set suitable for use by Canonical XML [XML-C14N]. Specifically,
dereferencing a null URI (URI="") must result in an XPath
node-set that includes every non-comment node of the XML document
containing the URI attribute. In a fragment URI, the
characters after the number sign ('#') character conform to the
XPointer syntax [XPTR-FRAMEWORK]. When processing an XPointer, the
application must behave as if the XPointer was evaluated with respect
to the XML document containing the URI attribute . The
application must behave as if the result of XPointer processing
[XPTR-FRAMEWORK] were a node-set derived from the resultant
subresource as follows:
- include XPath nodes having full or partial content within the
subresource
- replace the root node with its children (if it is in the node-set)
- replace any element node E with E
plus all descendants of E (text, comment, PI,
element) and all namespace and attribute nodes of E
and its descendant elements.
- if the URI has no fragment identifier or the fragment identifier
is a shortname XPointer, then delete all comment nodes
The second to last replacement is necessary because XPointer
typically indicates a subtree of an XML document's parse tree using
just the element node at the root of the subtree, whereas Canonical XML
treats a node-set as a set of nodes in which absence of descendant
nodes results in absence of their representative text from the
canonical form.
The last step is performed for null URIs and shortname XPointers .
It is necessary because when [XML-C14N] or [XML-C14N11] is passed
a node-set, it processes the node-set as is: with or without comments.
Only when it is called with an octet stream does it invoke its own
XPath expressions (default or without comments). Therefore to retain
the default behavior of stripping comments when passed a node-set, they
are removed in the last step if the URI is not a scheme-based XPointer.
To retain comments while selecting an element by an identifier ID,
use the following scheme-based XPointer: URI='#xpointer(id('ID'))'.
To retain comments while selecting the entire document, use the
following scheme-based XPointer: URI='#xpointer(/)'.
The interpretation of these XPointers is defined in The Reference Processing Model
(section 4.4.3.2).
4.4.3.8 The dsig2:Selection Element
The dsig2:Selection element describes the data being signed for a "2.0 Mode"
signature reference. The content and processing model for this element depends on the value of the required Type and an optional SubType attributes, which identifies the selection algorithm in use. The other attributes of dsig2:Selection
and any subelements are passed in as parameters to the selection
processing.
Schema Definition:
<xs:element name="Selection" type="dsig2:SelectionType"/>
<xs:complexType name="dsig2:SelectionType">
<xs:sequence>
<xs:any namespace="##any" minOccurs="0
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="URI" type="xs:anyURI" use="required"/>
<xs:attribute name="Type" type="xs:anyURI" use="required"/>
<xs:attribute name="Subtype" type="xs:string" use="optional"/>
</xs:complexType>
The Type (and optionally the SubType)
attribute is an extensibility point and users are allowed to add their
own types. Each type/subtype should define the parameters that is
expects, how they are laid out inside the Selection
element, how to process the Selection, what user defined object does
the selection produce, and what canonicalization algorithm to use to
canonicalize it into an octet stream.
The following values of Type and SubType
are defined by this specification.
Type="...xml" : Select complete XML documents, or
XML fragments.Type = "...binary" and Subtype = "...fromURI":
Select binary data from an external URI.Type = "...binary" and Subtype =
"...fromBase64Node": Select binary data from a base64 encoded
text node inside an XML document.
These algorithms are defined in 2.0 Mode Selection Algorithms. Users can define new types,
e.g. they can define a "text" type with associated text
canonicalization, or they can define a "DataBase rowset" type to sign
database content.
The result of processing the dsig2:Selection element must be one of the
following:
In the first case, a canonicalization algorithm compatible with these inputs must be applied to produce an octet stream for the digest algorithm.
The contents of the sibling CanonicalizationMethod element, if present, will specify the algorithm to use, and supply any non-default parameters to that algorithm. If no sibling CanonicalizationMethod element is present, then the XML Canonicalization 2.0 Algorithm [XML-C14N20] must be used with no non-default parameters.
For octet stream, no further processing is applied to the resulting octet stream, which will be supplied directly to the digest algorithm.
4.4.3.9 Subtrees with optional exclusions in 2.0 mode
Signture 2.0 does not use an XPath nodeset to represent an XML fragment to be signed. Instead it uses the following concept:
- The xml fragment to be signed is represented as one or more inclusion subtrees, and a set of zero or more exclusions consisting of subtrees and/or attribute nodes.
- Exclusions override inclusions, i.e. the selection constains all the nodes in the inclusion subtrees minus all the nodes in the exclusion subtrees.
- A "subtree" is a part of the xml document, consisting of all the descendants of an particular element node, or the document root node. The subtree is identfied by the element node/document root node.
- If in the inclusion list, one subtree is included in another one, the included one is effectively ignored.
- Each subtree (except when the subtree is the complete document), should have this additional information:
- The list of namespace declarations in context, i.e. inherited from the ancestors of this subtree.
- The inherited value of the
xml:space attribute.
- The inherited value of the
xml:base attribute. If there are multiple ancestor elements having xml:base they need to be combined together.
The last two are only required if the canonicalization requires them.
4.4.3.10 The URI Attribute for Selection in 2.0 mode
In "2.0 Mode", the URI attribute must be omitted in Reference and be present in the Selection.
The Selection's URI attribute is a a slightly simplified version of the Reference's URI
- Dereferencing is carried out in the context of the
Selection, i.e if the Type is "...xml, then the URI is dereferenced and then parsed into an XML document, whereas if the Type is "...binary" and SubType is "...fromURI" then the URI is dererefenced as an octet stream. Other user defined Type can specify different dereferencing mechanisms.
- Dereferencing a same-document reference does not result in a XPath node set. As mentioned in the previous bullet, referencing is in the context of the
Selection.
- In
Type="...xml" same document reference results in the entire document if URI="" or in a subtree is the URI refers to a fragment.
- In
Type="...binary" and SubType="...fromURI", same document references are not allowed.
- In
Type="...binary" and SubType="...fromBase64Node", same document references result in a subtree.
xpointer URIs are not supported.- There is no comment removal during URI dereferencing.
4.4.3.11 XPaths in 2.0 mode
The XPath mentioned in the IncludedXPath and ExcludedXPath are "normal" XPath, i.e. it is not
like the XPath in XPath Filter transform which is evaluated as a binary expression. Instead this
XPath is a path to the root of the
subtree being included or excluded. E.g. /book/chapter refers to the all chapter children of all book children
of root node. The IncludedXPath element should only select element nodes, whereas the ExcludedXPath element
can choose element or attribute nodes. Again this is consistent with the C14N 2.0 data model.
We have identified a profile of XPath, with the following goals in mind.
- The profile should produce results that are compatible with the C14N 2.0 data model. I.e it should
only result in element nodes or attribute nodes (but not xml: attribute and namespace
attributes).
- It should possible to execute this XPath in a streamable XPath implementation. The capabilities
of various streamable XPath implementations vary. Some XPaths cans be executed by even the most rudimentary
streaming XPath implementations e.g.
/book/chapter, whereas some can be executed by none of them e.g.
child::para[position()=last()-1]. Streaming XPath implementation by definition do a forward only
pass over the document, so knowing that a particular element's position is last but one, requires it to reach
the end and then backtrack. Streaming parsers read the document one "event" at a time. Usually the entire element tag including all the attributes
are read in a single event, however text nodes can are often split up into separate events because some text nodes
can be very large. So any XPath that requires comparison of text node value may not work in streaming XPath implementations.
- This XPath subset should include some of the known usages of XPath in XML Signatures.
- ebXML messages require a signature to exclude elements whose
@SOAP:actor attribute matches
a certain value. Refer section 4.1.3 of [[!EBXML-MSG"]]
- UK government specification requires signature to include the
GovTalkMessage/Body subtree, but exclude the
GovTalkMessage/Body/IRevenvelope/IRHeader/IRmark subtree. [[!HMRMC"]]
This subset can be expressed precisely using the following grammar, which is still under development.
Streamable XPath subset
|
Grammar
|
Explanation
|
|
[0a] IncludedXPath ::=
( LocationPath '|' )* LocationPath
[0b] ExcludedXPath ::=
( LocationPath '|' )* LocationPath
|
The Included and Excluded Xpath do not use the generic XPath Expr. Instead they are
just a union of LocationPath. There is a slight difference between IncludedXPath and
ExcludedXPath, ExcludedXpath can select attributes and element, whereas IncludedXPath can
only select elements.
|
|
[1] LocationPath ::=
RelativeLocationPath | AbsoluteLocationPath
[2] AbsoluteLocationPath ::=
'/' RelativeLocationPath? | AbbreviatedAbsoluteLocationPath
[3] RelativeLocationPath ::=
Step | RelativeLocationPath '/'
Step ( StepNoPredicate '/')* Step
| AbbreviatedRelativeLocationPath
|
- RelativeLocationPath is not allowed, only Absolute is allowed. This is because if
you use relative, it would probably mean relative to the <Signature> element, and
then you would have to support the ancestor axis to reach the other nodes, but that axis
is not streamable.
- Only the last Step can have a predicate. So I have created a non-terminal
"StepNoPredicate"
|
|
[4] Step ::=
AxisSpecifier NodeTest Predicate* | AbbreviatedStep
[4a] StepNoPredicate ::=
AxisSpecifier NodeTest | AbbreviatedStep
[4b] StepAttributeOnly ::=
'attribute' '::' NameTest | '@' '::' NameTest
|
Added two new versions of Step.
One is a Step with no Predicate, and the
other is a step attribute only
e.g. in this XPath expression:
/doc/chapter[@type="warning"]
/doc is StepNoPredicatechapter[@type="warning"] is Step@type is StepAttributeOnly
|
|
[5] AxisSpecifier ::=
AxisName '::' | AbbreviatedAxisSpecifier
|
unchanged
|
|
[6] AxisName ::=
'ancestor'
| 'ancestor-or-self'
| 'attribute'
| 'child'
| 'descendant'
| 'descendant-or-self'
| 'following'
| 'following-sibling'
| 'namespace'
| 'parent'
| 'preceding'
| 'preceding-sibling'
| 'self'
|
All the non streamable axes have been removed - ancestor, ancestor-or-self, following,
following-sibling, namespace, parent, preceding, preceding-sibling
|
|
[7] NodeTest ::=
NameTest | NodeType '(' ')'
| 'processing-instruction' '(' Literal ')'
|
processing instruction test is not allowed.
only the node() node test is allowed, not comment(), text() and
processing-instruction()
|
|
[8] Predicate ::= '[' PredicateExpr ']'
[9] PredicateExpr ::= Expr
|
unchanged
but the definition of Expr has changed, so it is only a additive/relative expressions
of StepAttributeOnly and Literals.
|
|
[10] AbbreviatedAbsoluteLocationPath ::=
'//' RelativeLocationPath
[11] AbbreviatedRelativeLocationPath ::=
RelativeLocationPath '//' Step
[12] AbbreviatedStep ::= '.' | '..'
[13] AbbreviatedAxisSpecifier ::= '@'?
|
unchanged
|
|
[14] Expr ::= OrExpr
[15] PrimaryExpr ::=
VariableReference
| '(' Expr ')'
| Literal
| Number
| FunctionCall
|
unchanged
|
|
[16] FunctionCall ::= FunctionName '(' ( Argument ( ',' Argument )* )? ')'
[17] Argument ::= Expr
|
unchanged
|
|
[18] UnionExpr ::=
PathExpr | UnionExpr '|' PathExpr
[19] PathExpr ::=
LocationPath
| FilterExpr
| FilterExpr '/' RelativeLocationPath
| FilterExpr '//' RelativeLocationPath
[20] FilterExpr ::= PrimaryExpr
| FilterExpr Predicate
|
UnionExpr, PathExpr and FilterExpr have been removed.
|
|
[21] OrExpr ::=
AndExpr | OrExpr 'or' AndExpr
[22] AndExpr ::=
EqualityExpr | AndExpr 'and' EqualityExpr
[23] EqualityExpr ::=
RelationalExpr
| EqualityExpr '=' RelationalExpr
| EqualityExpr '!=' RelationalExpr
[24] RelationalExpr ::= AdditiveExpr
| RelationalExpr '<' AdditiveExpr
| RelationalExpr '>' AdditiveExpr
| RelationalExpr '<=' AdditiveExpr
| RelationalExpr '>=' AdditiveExpr
|
unchanged
|
|
[25] AdditiveExpr ::=
MultiplicativeExpr
| AdditiveExpr '+' MultiplicativeExpr
| AdditiveExpr '-' MultiplicativeExpr
[26] MultiplicativeExpr ::= UnaryExpr
| MultiplicativeExpr MultiplyOperator UnaryExpr
| MultiplicativeExpr 'div' UnaryExpr
| MultiplicativeExpr 'mod' UnaryExpr
[27] UnaryExpr ::= UnionExpr
PrimaryExpr
| StepAttributeOnly
| '-' UnaryExpr
|
The unaryExpr is changed to only allow a PrimaryExpr or StepAttributeOnly
|
|
[28] ExprToken ::=
'(' | ')' | '[' | ']' | '.' | '..' | '@' | ',' | '::'
| NameTest
| NodeType
| Operator
| FunctionName
| AxisName
| Literal
| Number
| VariableReference
[29] Literal ::= '"' [^"]* '"' | "'" [^']* "'"
[30] Number ::= Digits ('.' Digits?)? | '.' Digits
[31] Digits ::= [0-9]+
[32] Operator ::=
OperatorName | MultiplyOperator
| '/' | '//' | '|' | '+' | '-' | '=' | '!='
| '<' | '<=' | '>' | '>='
[33] OperatorName ::=
'and' | 'or' | 'mod' | 'div'
[34] MultiplyOperator ::= '*'
[35] FunctionName ::= QName - NodeType
[36] VariableReference ::= '$' QName
[37] NameTest ::=
'*' | NCName ':' '*' | QName
[38] NodeType ::=
'comment'
| 'text'
| 'processing-instruction'
| 'node'
[39] ExprWhitespace ::= S
|
unchanged, expect for the NodeTest
|
|
Node set functions
-
last()
-
position()
-
count(nodeset)
-
id()
-
local-name(nodeset)
-
namespace-uri(nodeset)
-
name(nodeset)
String functions
-
string(object)
-
concat(string, string, string*)
-
starts-with(string, string)
-
contains(string, string)
-
substring-before(string, string)
-
substring-after(string, string)
-
substring(string, number, number)
-
string-length(string?)
-
normalize-space(string?)
Boolean functions
-
boolean(object)
-
true()
-
false()
-
lang(string)
Number functions
-
number(object?)
-
sum(node-set)
-
floor(number)
-
ceiling(number)
-
round(number)
|
Note:
As mentioned before, only the last Step can have a Predicate, and this predicate's
expression can only involve attribute nodes of the current element. Functions can only be
used inside this last step's predicate, and this function can only accept a single
attribute as an argument. There is no way to use element names, text nodes,
comments and processing instructions in functions.
The "string-value" become just the attributes value.
All functions involving context position and context size are not supported i.e.. last,
position, count or their shortcut versions e.g. foo[1]. the streaming parser cannot
maintain counts.
String, number and boolean functions are all supported.
|
Here is an algorithm for Streaming XPath. For simplicity this algorithm
assumes that excludedXPath is not present:
For parsing:
- Split up the union expression by
"|". i.e.
break up the locationPath | locationPath | .. into individual
location paths.
- Split up each location paths to get individual steps and the
final predicate. i.e. break up the
/ step / step / step .. / step [
predicate ] to get the steps and optional predicate. Two slashes
together indicates descendant axis.
- The predicate will have an expression involving attribute names e.g.
@a = "foo" and @b > "bar"
You need to have an expression parsing and evaluating engine to do this.
For executing:
- A streaming XML Parser (e.g. StAX), reads an XML document and produces
"events" like StartElement, EndElement, TextNode etc. At any point this parser
only remembers the current node. If the current node is an start
element, then it also
reads all the attributes for that element. To execute a streaming XPath you maintain a stack
of ancestor element names, i.e whenever you get a StartElement tag,
you need to push the element
QName onto this stack, and when you get an EndElement tag you need to pop it off.
- As you stream through the nodes, you need to execute this XPath expression for every node.
I.e. utilize the current element, the current element's attributes and the stack of ancestors
to evaluate the XPath expression.
For each locationPath, match up the steps to the ancestor stack,
If they match, evaluate the predicate with the current element's
expression. If that passes too, this element and all its descendants are
included.
4.4.3.12 The DigestMethod Element
DigestMethod is a required element that identifies the
digest algorithm to be applied to the signed object. This element uses
the general structure here for algorithms specified in Algorithm Identifiers and
Implementation Requirements (section 6.1).
For "Compatibility Mode" signatures, if the result of the URI
dereference and application of Transforms is an XPath node-set (or
sufficiently functional replacement implemented by the application)
then it must be converted as described in the "Compatibility Mode"
Reference Processing Model (section 4.4.3.2). If the result of URI
dereference and application of transforms is an octet stream, then no
conversion occurs (comments might be present if the Canonical XML with
Comments was specified in the Transforms). The digest algorithm is
applied to the data octets of the resulting octet stream.
For "2.0 Mode" signatures, the result of processing the Reference
is an octet stream, and the digest algorithm is applied to the
resulting data octets.
Schema Definition:
<element name="DigestMethod" type="ds:DigestMethodType"/>
<complexType name="DigestMethodType" mixed="true">
<sequence>
<any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="Algorithm" type="anyURI" use="required"/>
</complexType>
4.4.3.13 The DigestValue Element
DigestValue is an element that contains the encoded value of the
digest. The digest is always encoded using base64 [RFC2045].
Schema Definition:
<element name="DigestValue" type="ds:DigestValueType"/>
<simpleType name="DigestValueType">
<restriction base="base64Binary"/>
</simpleType>