Copyright © 2008 W3C , All Rights Reserved.
This document defines interoperability test cases for Canonical XML 1.1 [XML-C14N1.1] and XML Signature Syntax and Processing, Second Edition [XMLDSIG2]. The changes tested include C14N11 handling of attributes in the XML namespace, including xml:id and xml:base, appropriate C14N11 nodeset to octet stream transform processing, modifications to RFC 3986 dot segment processing for C14N11, and RFC 4514 string encoding of Distinguished Names. The tests include standalone C14N11 tests as well as tests integrated with XML signature generation and validation. This document also includes earlier test cases used in XML Signature [XMLDSIG] for regression testing.
This document is a working document of the World Wide Web Consortium XML Security Specifications Maintenance Working Group. For further details of the activity of this group, please see the XML Security Specifications Maintenance Working Group.
1 Introduction
1.1 Test Case
Notation
1.2 Codes for
Recommendation References (Rec, SubRec)
1.3 Codes for Issues
(SpecificIssue) and Sub-Issues (SpecificSubIssue)
2 Test Cases specification
2.1 Legacy XMLDSig Working
Group Test Cases
2.2 Test Cases for
Canonicalization 1.1
2.2.1 Test Cases for xml:lang
attribute
2.2.2 Test Cases for xml:space
attribute
2.2.3 Test Cases for xml:id
attribute
2.2.4 Test Cases for xml:base
attribute
<IP_ADDRESS> Test Cases
for checking xml:base attribute propagation
<IP_ADDRESS> Test Cases
for checking XML-C14N1.1 specification tests
2.2.5 Test Cases for
checking examples in the XML-C14N1.1 Appendix
2.3 Test Cases for
XMLDSig
2.3.1 Test Cases
for C14N 1.1 in XMLDSig
2.3.2 Test Cases on
nodeset to octet-stream conversion by C14n 1.1 explicitly
reflected in the chain of transforms
2.3.3 Test
Cases on schema based XPointers and canonicalization
2.3.4 Test Cases
on String encoding of Distinguished Names
<IP_ADDRESS> Test Cases on
differences identified in RFC 2253 and RFC 4514
<IP_ADDRESS> Test Cases for RFC
4514
3 References
The test cases include standalone C14N 1.1 tests and test cases involving XML signature generation and validation. XML signatures are generated according to the details specified in this document.
All the test cases are positive (signatures that are valid).
Applications should validate these signatures and check that they are valid.
This section summarizes the notation used for identification of test cases.
A test case identifier matches the following pattern, and the syntax for describing the pattern is borrowed from section 2.0 of [XMLDSIG] (where "?" denotes zero or one occurrence; "+" denotes one or more occurrences; "*" denotes zero or more occurrences) and "|" denotes a choice.
Rec/(SubRec/)?(SpecificIssue-(SpecificSubIssue-)?)+TestNumber |
The Rec
part identifies the source
recommendation for the test case.
The SubRec
part identifies a recommendation
that is tested in the context of Rec
.
The SpecificIssue
part identifies the issue
to be tested by the test case. The optional
SpecificSubIssue
part further refines the
issue to be tested.
The TestNumber
part numbers the test case.
It must be an integer number or an integer number followed
by a lowercase letter.
The next section identifies codes used throughout this document.
Rec
,
SubRec
)The following codes are used for identifying the source recommendations for the test cases:
c14n11
identifies the standalone
[XML-C14N1.1] test
cases.
xmldsig
identifies the [XMLDSIG2] test cases.
c14n11
identifies the test cases
that test c14n11
with
xmldsig
.
dname
identifies the test cases
that test [RFC-4514] versus
[RFC-2253] with
xmldsig
.
xpointer
identifies the test cases
that test [XPointer-Framework],
[XPointer-Element]
and [XPointer-xpointer] with
xmldsig
.
This structure is reflected in the directories c14n11/, xmldsig/, xmldsig/c14n11/, xmldsig/dname/ and xmldsig/xpointer/.
SpecificIssue
) and Sub-Issues
(SpecificSubIssue
)The following codes are used for identifying the issues and sub-issues for the test cases:
defCan
identifies the test cases that
test the [XMLDSIG2] implicit
and explicit rules managing the final canonicalization
that precedes the digest computation..
xmllang
identifies the test cases that
test the C14N11 handling of the xml:lang
attribute.
xmlspace
identifies the test cases that
test the C14N11 handling of the xml:space
attribute.
xmlid
identifies the test cases that
test the C14N11 handling of the xml:id
attribute.
xmlbase
identifies the test cases that
test the C14N11 handling of the xml:base
attribute.
The following sub-issues are associated with this issue:
prop
identifies the test cases that
test the C14N11 propagation of the
xml:base
attribute through the node
tree.
annexA
identifies the test cases
that test the C14N11 Remove Dot Segments examples
listed in Appendix A of [XML-C14N1.1].
c14n11spec
identifies the test
cases that test the examples in the [XML-C14N1.1] specification.
dnString
identifies the test cases that
test the string encoding of Distinguished Names.
diffRFCs
identifies the test cases that
test the differences between [RFC-2253] and [RFC-4514].
xpointer
identifies the test cases that
test the handling of XPointer Reference URIs as
specified in [XMLDSIG2]
The following sub-sections describe each of the test cases and are grouped by Recommendation and Issue.
The IETF/W3C XML-DSig Working Group produced an interoperability test matrix that can be found at [XMLDSIG-interop].
The set of test cases in this section are designed to test the C14N11 handling of attributes in the xml namespace. The input for each of these test cases is an XML document and an XPath document subset expression. Two different sets of tests are included based on the test cases in this section.
Standalone tests: no XML signature generation or validation is required. The XPath document subset expression is applied to the input document. These tests are used to check that the implementation for [XML-C14N1.1] behaves correctly.
Integrated tests with XML signatures: In these set of tests, an XML signature is generated based on the input document and a corresponding XPath Filtering Transform as indicated in the tables. For these set of tests, the following rules apply:
The XML Signature is generated using the
HMAC-SHA1 SignatureMethod algorithm and a secret
key with the value:
"secret".getBytes("ASCII")
.
The Transforms
element contains a
sequence of two transforms:
An XPath Filtering Transform that contains an XPath expression that depends on the test case.
A Canonical XML 1.1 Transform.
xml:lang
attributeThe set of test cases in this section test the C14N11
handling of xml:lang
attributes.
Below is the input document for the test cases in this section:
<?xml version="1.0" encoding="UTF-8"?> <ietf:c14n11Xmllang xmlns:ietf="http://www.ietf.org" xmlns:w3c="http://www.w3.org"> <ietf:e1 xml:lang="EN"> <ietf:e11> <ietf:e111 /> </ietf:e11> <ietf:e12 at="2"> <ietf:e121 /> </ietf:e12> </ietf:e1> <ietf:e2 > <ietf:e21 /> </ietf:e2> </ietf:c14n11Xmllang> |
Note:
Document subset expressions for document subsets computation are defined as in [XML-C14N1.1].
| Test case c14n11/xmllang-1 | |
|---|---|
| Input details | To-Be-Signed (TBS
henceforth) data object with ONLY a
xml:lang attribute in a certain
element e whose content includes other
elements. The ds:Transform contains a
XPath expression whose result is a node set that
includes element e . |
| Rationale | Check that implementations of [XML-C14N1.1] handle xml:lang attributes as defined in [XML-C14N1.1] |
| Document subset expression | (//. | //@* | //namespace::*)[ancestor-or-self::ietf:e1] |
| Output |
<ietf:e1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org" xml:lang="EN"> <ietf:e11> <ietf:e111></ietf:e111> </ietf:e11> <ietf:e12 at="2"> <ietf:e121></ietf:e121> </ietf:e12> </ietf:e1> |
| Test case c14n11/xmllang-2 | |
|---|---|
| Input details | TBS data object with
ONLY a xml:lang attribute in a certain
element e whose content includes other
elements. The ds:Transform contains a
XPath expression whose result is a node set that
DOES NOT include neither element e nor
any of its children elements. |
| Rationale | Check that implementations of [XML-C14N1.1] handle xml:lang attributes as defined in [XML-C14N1.1] |
| Document subset expression | (//. | //@* | //namespace::*)[ancestor-or-self::ietf:e2] |
| Output |
<ietf:e2 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"> <ietf:e21></ietf:e21> </ietf:e2> |
| Test case c14n11/xmllang-3 | |
|---|---|
| Input details | TBS with ONLY a
xml:lang attribute in a certain
element e whose content includes a
sequence of one element. The
ds:Transform contains a XPath
expression whose result is a node set that DOES NOT
include element e but includes one
child element. |
| Rationale | Check that implementations of [XML-C14N1.1] handle xml:lang attributes as defined in [XML-C14N1.1] |
| Document subset expression | (//. | //@* | //namespace::*)[ancestor-or-self::ietf:e11] |
| Output |
<ietf:e11 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org" xml:lang="EN"> <ietf:e111></ietf:e111> </ietf:e11> |
| Test case c14n11/xmllang-4 | |
|---|---|
| Input details | TBS with ONLY a
xml:lang attribute in a certain
element e whose content includes a
sequence of more than one element (these children
may in turn contain children elements). The
ds:Transform contains a XPath
expression whose result is a node set that DOES NOT
include element e but includes more
than one of its children elements. |
| Rationale | Check that implementations of [XML-C14N1.1] handle xml:lang attributes as defined in [XML-C14N1.1] |
| Document subset expression | (//. | //@* | //namespace::*)[ancestor-or-self::ietf:e11 or ancestor-or-self::ietf:e12] |
| Output |
<ietf:e11 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org" xml:lang="EN"> <ietf:e111></ietf:e111> </ietf:e11>\ + <ietf:e12 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org" at="2" xml:lang="EN"> <ietf:e121></ietf:e121> </ietf:e12> |
xml:space
attributeThe set of test cases in this section test the C14N11
handling of xml:space
attributes.
Below is the input document for the test cases in this section:
<?xml version="1.0" encoding="UTF-8"?> <ietf:c14n11XmlSpaceDoc1 xmlns:ietf="http://www.ietf.org" xmlns:w3c="http://www.w3.org"> <ietf:e1 xml:space="true"> <ietf:e11> <ietf:e111 /> </ietf:e11> <ietf:e12 at="2"> <ietf:e121 /> </ietf:e12> </ietf:e1> <ietf:e2 > <ietf:e21 /> </ietf:e2> </ietf:c14n11XmlSpaceDoc1> |
| Test case c14n11/xmlspace-1 | |
|---|---|
| Input details | TBS data object with
ONLY a xml:space attribute in a
certain element e whose content
includes other elements. The
ds:Transform contains a XPath
expression whose result is a node set that includes
element e . |
| Rationale | Check that implementations of [XML-C14N1.1] handle xml:space attributes as defined in [XML-C14N1.1] |
| Document subset expression | (//. | //@* | //namespace::*) [ancestor-or-self::ietf:e1] |
| Output |
<ietf:e1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org" xml:space="true"> <ietf:e11> <ietf:e111></ietf:e111> </ietf:e11> <ietf:e12 at="2"> <ietf:e121></ietf:e121> </ietf:e12> </ietf:e1> |
| Test case c14n11/xmlspace-2 | |
|---|---|
| Input details | TBS data object with
ONLY a xml:space attribute in a
certain element e whose content
includes other elements. The
ds:Transform contains a XPath
expression whose result is a node set that DOES NOT
include neither element e nor any of
its children elements. |
| Rationale | Check that implementations of [XML-C14N1.1] handle xml:space attributes as defined in [XML-C14N1.1] |
| Document subset expression | (//. | //@* | //namespace::*) [ancestor-or-self::ietf:e2] |
| Output |
<ietf:e2 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"> <ietf:e21></ietf:e21> </ietf:e2> |
| Test case c14n11/xmlspace-3 | |
|---|---|
| Input details | TBS with ONLY a
xml:space attribute in a certain
element e whose content includes a
sequence of one element. The
ds:Transform contains a XPath
expression whose result is a node set that DOES NOT
include element e but includes its
child element. |
| Rationale | Check that implementations of [XML-C14N1.1] handle xml:space attributes as defined in [XML-C14N1.1] |
| Document subset expression | (//. | //@* | //namespace::*) [ancestor-or-self::ietf:e11] |
| Output |
<ietf:e11 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org" xml:space="true"> <ietf:e111></ietf:e111> </ietf:e11> |
| Test case c14n11/xmlspace-4 | |
|---|---|
| Input details | TBS with ONLY a
xml:space attribute in a certain
element e whose content includes a
sequence of more than one element (these children
may in turn contain children elements). The
ds:Transform contains a XPath
expression whose result is a node set that DOES NOT
include element e but includes more
than one of its children elements. |
| Rationale | Check that implementations of [XML-C14N1.1] handle xml:space attributes as defined in [XML-C14N1.1] |
| Document subset expression | (//. | //@* | //namespace::*) [ancestor-or-self::ietf:e11 or ancestor-or-self::ietf:e12] |
| Output |
<ietf:e11 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org" xml:space="true"> <ietf:e111></ietf:e111> </ietf:e11>\ + <ietf:e12 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org" at="2" xml:space="true"> <ietf:e121></ietf:e121> </ietf:e12> |
xml:id
attributeThe set of test cases in this section test the C14N11
handling of xml:id
attributes.
Below is the input document for all the test cases in this section:
<?xml version="1.0" encoding="UTF-8"?> <ietf:c14n11XmlIdDoc1 xmlns:ietf="http://www.ietf.org" xmlns:w3c="http://www.w3.org"> <ietf:e1 xml:id="IdInterop"> <ietf:e11> <ietf:e111 /> </ietf:e11> <ietf:e12 at="2"> <ietf:e121 /> </ietf:e12> </ietf:e1> <ietf:e2 > <ietf:e21 /> </ietf:e2> </ietf:c14n11XmlIdDoc1> |
| Test case c14n11/xmlid-1 | |
|---|---|
| Input details | TBS with ONLY a
xml:id attribute in a certain element
e whose content includes other
elements. The ds:Transform contains a
XPath expression whose result is a node set that
includes element e . |
| Rationale | Check that implementations of [XML-C14N1.1] handle xml:id attributes as defined in [XML-C14N1.1] |
| Document subset expression | (//. | //@* | //namespace::*) [ancestor-or-self::ietf:e1] |
| Output |
<ietf:e1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org" xml:id="IdInterop"> <ietf:e11> <ietf:e111></ietf:e111> </ietf:e11> <ietf:e12 at="2"> <ietf:e121></ietf:e121> </ietf:e12> </ietf:e1> |
| Test case c14n11/xmlid-2 | |
|---|---|
| Input details | TBS with ONLY a
xml:id attribute in a certain element
e whose content includes other
elements. The ds:Transform contains a
XPath expression whose result is a node set that
DOES NOT include the element e but
some of the children of the element
e . |
| Rationale | Check that implementations of [XML-C14N1.1] handle xml:id attributes as defined in [XML-C14N1.1] |
| Document subset expression | (//. | //@* | //namespace::*) [ancestor-or-self::ietf:e11 or ancestor-or-self::ietf:e12] |
| Output |
<ietf:e11 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"> <ietf:e111></ietf:e111> </ietf:e11>\ + <ietf:e12 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org" at="2"> <ietf:e121></ietf:e121> </ietf:e12> |
xml:base
attributeThe set of test cases in this section test the C14N11
handling of xml:base
attributes.
Three sets of test cases have been defined:
Tests that check if the implementation correctly
propagates the xml:base
attributes
through the node tree.
Tests that check if the implementation correctly processes the examples involving xml:base propagation in the [XML-C14N1.1] specification.
Tests that check if the implementation correctly processes the examples in the Appendix of [XML-C14N1.1]
xml:base
attribute
propagationThis section defines test cases that test how
implementations propagate xml:base
attributes through the tree when the result of the
filtering is a document subset.
Below is the input document for the test cases in this section:
<?xml version="1.0" encoding="UTF-8"?> <ietf:c14n11XmlBaseDoc1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"\ + xml:base="http://xmlbase.example.org/xmlbase0/"> <ietf:e1 xml:base="/xmlbase1/"> <ietf:e11 xml:base="/xmlbase11/"> <ietf:e111 xml:base="/xmlbase111/"/> </ietf:e11> <ietf:e12 at="2"> <ietf:e121 xml:base="/xmlbase121/"/> </ietf:e12> </ietf:e1> <ietf:e2> <ietf:e21 xml:base="/xmlbase21/"/> </ietf:e2> <ietf:e3> <ietf:e31 at="3"/> </ietf:e3> </ietf:c14n11XmlBaseDoc1> |
The document's root element
ietf:c14n11XmlBaseDoc1
defines an
xml:base
attribute. This element contains
three children elements.
The first element ietf:e1
has another
xml:base
attribute. All the
ietf:e1
's descendant elements have a
xml:base
attribute. Transforms that select
subsets of ietf:e1
's descendants will test
how each level in the tree of elements incorporates its
corresponding part to the value of the final
xml:base
.
The second element ietf:e2
does not
have a xml:base
attribute, but its child
element, ietf:e21
has a
xml:base
attribute. Transforms that select
ietf:e21
will test how it takes the value
of xml:base
from an ancestor different
than its parent.
As for the third element, neither it nor any of its
descendants have a xml:base
attribute.
Transforms that select ietf:e3
or any of
its descendants will test how they inherit the
xml:base
attribute from the root element
without any further processing.
| Test case c14n11/xmlbase-prop-1 | |
|---|---|
| Input details | The document shown
above. The ds:Transform contains a
XPath expression whose result is a node set that
includes element
ietf:c14n11XmlBaseDoc1 and the child
ietf:e1 and its descendant. |
| Rationale | Check that
implementations of [XML-C14N1.1] work properly
when the xml:base origin appears in
the output document subset and also children with
xml:base , which do not require
further processing, are also present. |
| Document subset expression | (//. | //@* | //namespace::*) [ancestor-or-self::ietf:c14n11XmlBaseDoc1 and not(ancestor-or-self::ietf:e2)] |
| Output |
<ietf:c14n11XmlBaseDoc1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"\ + xml:base="http://xmlbase.example.org/xmlbase0/"> <ietf:e1 xml:base="/xmlbase1/"> <ietf:e11 xml:base="/xmlbase11/"> <ietf:e111 xml:base="/xmlbase111/"></ietf:e111> </ietf:e11> <ietf:e12 at="2"> <ietf:e121 xml:base="/xmlbase121/"></ietf:e121> </ietf:e12> </ietf:e1> <ietf:e3> <ietf:e31 at="3"></ietf:e31> </ietf:e3> </ietf:c14n11XmlBaseDoc1> |
| Test case c14n11/xmlbase-prop-2 | |
|---|---|
| Input details | The document shown
above. The ds:Transform contains a
XPath expression whose result is a node set that
includes element ietf:e1 and its
descendant but not
ietf:c14n11XmlBaseDoc1 . |
| Rationale | Check that
implementations of [XML-C14N1.1] properly build
the xml:base at the first level
(ietf:e1 ). |
| Document subset expression | (//. | //@* | //namespace::*) [ancestor-or-self::ietf:e1] |
| Output |
<ietf:e1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"\ + xml:base="http://xmlbase.example.org/xmlbase1/"> <ietf:e11 xml:base="/xmlbase11/"> <ietf:e111 xml:base="/xmlbase111/"></ietf:e111> </ietf:e11> <ietf:e12 at="2"> <ietf:e121 xml:base="/xmlbase121/"></ietf:e121> </ietf:e12> </ietf:e1> |
| Test case c14n11/xmlbase-prop-3 | |
|---|---|
| Input details | The document shown
above. The ds:Transform contains a
XPath expression whose result is a node set that
includes element ietf:e11 and its
descendant. Elements
ietf:c14n11XmlBaseDoc1 and
ietf:e1 do not appear. |
| Rationale | Check that
implementations of [XML-C14N1.1] properly build
the xml:base if one of intermediate
the levels (ietf:e1 ) are absent from
the document subset. |
| Document subset expression | (//. | //@* | //namespace::*) [ancestor-or-self::ietf:e11] |
| Output |
<ietf:e11 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"\ + xml:base="http://xmlbase.example.org/xmlbase11/"> <ietf:e111 xml:base="/xmlbase111/"></ietf:e111> </ietf:e11> |
| Test case c14n11/xmlbase-prop-4 | |
|---|---|
| Input details | The document shown
above. The ds:Transform contains a
XPath expression whose result is a node set that
includes element ietf:e111 and its
descendant. Elements
ietf:c14n11XmlBaseDoc1 ,
ietf:e11 and ietf:e1 do
not appear. |
| Rationale | Check that
implementations of [XML-C14N1.1] properly build
the xml:base if several intermediate
levels (ietf:e1 and
ietf:e11 ) are absent from the
document subset. |
| Document subset expression | (//. | //@* | //namespace::*) [ancestor-or-self::ietf:e111] |
| Output |
<ietf:e111 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"\ + xml:base="http://xmlbase.example.org/xmlbase111/"></ietf:e111> |
| Test case c14n11/xmlbase-prop-5 | |
|---|---|
| Input details | The document shown
above. The ds:Transform contains a
XPath expression whose result is a node set that
includes element ietf:e2 and its
descendant. Elements
ietf:c14n11XmlBaseDoc1 ,
ietf:e1 and its descendant, and
ietf:e3 and its descendant do not
appear. |
| Rationale | Check that
implementations of [XML-C14N1.1] properly build
the xml:base if one intermediate
level (ietf:e2 ) without any
xml:base attribute is absent from
the document subset. |
| Document subset expression | (//. | //@* | //namespace::*) [ancestor-or-self::ietf:e21] |
| Output |
<ietf:e21 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"\ + xml:base="http://xmlbase.example.org/xmlbase21/"></ietf:e21> |
| Test case c14n11/xmlbase-prop-6 | |
|---|---|
| Input details | The document shown
above. The ds:Transform contains a
XPath expression whose result is a node set that
includes element ietf:e3 and its
descendant. Elements
ietf:c14n11XmlBaseDoc1 ,
ietf:e1 and its descendant, and
ietf:e2 and its descendant do not
appear. |
| Rationale | Check that
implementations of [XML-C14N1.1] properly build
the xml:base in one element that
originally had no xml:base
attribute. |
| Document subset expression | (//. | //@* | //namespace::*) [ancestor-or-self::ietf:e3] |
| Output |
<ietf:e3 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"\ + xml:base="http://xmlbase.example.org/xmlbase0/"> <ietf:e31 at="3"></ietf:e31> </ietf:e3> |
| Test case c14n11/xmlbase-prop-7 | |
|---|---|
| Input details | The document shown
above. The ds:Transform contains a
XPath expression whose result is a node set that
includes elements
ietf:c14n11XmlBaseDoc1 and
ietf:e3 and its descendant. Elements
ietf:e1 and its descendant, and
ietf:e2 and its descendant do not
appear. |
| Rationale | Check that
implementations of [XML-C14N1.1] do not pass the
xml:base to another element when it
is not necessary. |
| Document subset expression | (//. | //@* | //namespace::*) [ancestor-or-self::ietf:c14n11XmlBaseDoc1 and not(ancestor-or-self::ietf:e1 or ancestor-or-self::ietf:e2)] |
| Output |
<ietf:c14n11XmlBaseDoc1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"\ + xml:base="http://xmlbase.example.org/xmlbase0/"> <ietf:e3> <ietf:e31 at="3"></ietf:e31> </ietf:e3> </ietf:c14n11XmlBaseDoc1> |
This section defines test cases that are based on
the examples in the C14N11 specification that propagate
xml:base
attributes through the tree when
the result of the filtering is a document subset.
Below is the input document from section 3.8 of [XML-C14N1.1] for the test case c14n11/xmlbase-c14n11spec-102 below:
<!DOCTYPE doc [ <!ATTLIST e2 xml:space (default|preserve) 'preserve'> <!ATTLIST e3 id ID #IMPLIED> ]> <doc xmlns="http://www.ietf.org" xmlns:w3c="http://www.w3.org"\ + xml:base="http://www.example.com/something/else"> <e1> <e2 xmlns="" xml:id="abc" xml:base="../bar/"> <e3 id="E3" xml:base="foo"/> </e2> </e1> </doc> |
| Test case c14n11/xmlbase-c14n11spec-102 | |
|---|---|
| Input details | The input document shown above. |
| Rationale | Check that correct xml:base fixup is performed. |
| Document subset expression | (//. | //@* | //namespace::*)[self::ietf:e1 or (parent::ietf:e1 and not(self::text() or self::e2)) or count(id("E3")|ancestor-or-self::node()) = count(ancestor-or-self::node())] |
| Output |
<e1 xmlns="http://www.ietf.org" xmlns:w3c="http://www.w3.org"\ + xml:base="http://www.example.com/something/else">\ + <e3 xmlns="" id="E3" xml:base="../bar/foo" xml:space="preserve">\ + </e3></e1> |
Below is the input document similar to the example from section 3.8 of [XML-C14N1.1] for the test case c14n11/xmlbase-c14n11spec-102 below. The main difference is that the value of the xml:base attribute of the e2 element is "bar/" instead of "../bar".
<!DOCTYPE doc [ <!ATTLIST e2 xml:space (default|preserve) 'preserve'> <!ATTLIST e3 id ID #IMPLIED> ]> <doc xmlns="http://www.ietf.org" xmlns:w3c="http://www.w3.org"\ + xml:base="something/else"> <e1> <e2 xmlns="" xml:id="abc" xml:base="bar/"> <e3 id="E3" xml:base="foo"/> </e2> </e1> </doc> |
| Test case c14n11/xmlbase-c14n11spec2-102 | |
|---|---|
| Input details | The input document shown above. |
| Rationale | Check that correct xml:base fixup is performed. |
| Document subset expression | (//. | //@* | //namespace::*)[self::ietf:e1 or (parent::ietf:e1 and not(self::text() or self::e2)) or count(id("E3")|ancestor-or-self::node()) = count(ancestor-or-self::node())] |
| Output |
<e1 xmlns="http://www.ietf.org" xmlns:w3c="http://www.w3.org"\ + xml:base="something/else">\ + <e3 xmlns="" id="E3" xml:base="bar/foo" xml:space="preserve">\ + </e3></e1> |
Below is the input document from section 2.4 of [XML-C14N1.1] for the test case c14n11/xmlbase-c14n11spec-103 below.
<?xml version="1.0" encoding="UTF-8"?> <a xml:base="foo/bar"> <b xml:base=".."> <c xml:base=".."> <d xml:base="x"> </d> </c> </b> </a> |
| Test case c14n11/xmlbase-c14n11spec3-103 | |
|---|---|
| Input details | The input document shown above. |
| Rationale | Check that correct xml:base fixup is performed. This test illustrates the modification of the "Remove Dot Segments" algorithm. |
| Document subset expression | (//. | //@* | //namespace::*) [self::a or ancestor-or-self::d] |
| Output |
<a xml:base="foo/bar"><d xml:base="../../x"> </d></a> |
This section defines test cases for checking if implementations are compliant with [XML-C14N1.1], specifically the normative rules in the Document Subsets section. Informative examples are given in the Appendix of C14N11.
Each test case in this section specifies an input string, representing a URI that must be processed according to the modified Remove Dot Segments algorithm described in Section 2.4 (Document Subsets) of [XML-C14N1.1].
Each test case appears in a row of the table shown below. The first column identifies the input URI that has to be processed. The second column shows the corresponding output.
| Test case c14n11/xmlbase-annexa | |
|---|---|
| inputs.txt | outputs.txt |
no/.././/pseudo-netpath/seg/file.ext no/..//.///pseudo-netpath/seg/file.ext yes/no//..//.///pseudo-netpath/seg/file.ext no/../yes no/../yes/ no/../yes/no/.. ../../no/../.. no/../.. no/.. no/../ /a/b/c/./../../g mid/content=5/../6 ../../.. no/../../ ..yes/..no/..no/..no/../../../..yes ..yes/..no/..no/..no/../../../..yes/ ../.. ../../../ . ./ ./. //no/.. ../../no/.. ../../no/../ yes/no/../ yes/no/no/../.. yes/no/no/no/../../.. yes/no/../yes/no/no/../.. yes/no/no/no/../../../yes yes/no/no/no/../../../yes/ /no/../ /yes/no/../ /yes/no/no/../.. /yes/no/no/no/../../.. ../../..no/.. ../../..no/../ ..yes/..no/../ ..yes/..no/..no/../.. ..yes/...no/..no/..no/../../.. ..yes/..no/../..yes/..no/..no/../.. /..no/../ /..yes/..no/../ /..yes/..no/..no/../.. /..yes/..no/..no/..no/../../.. / /. /./ /./. /././ /.. /../.. /../../.. /../../.. //.. //..//.. //..//..//.. /./.. /./.././.. /./.././.././.. . ./ ./. .. ../ |
pseudo-netpath/seg/file.ext pseudo-netpath/seg/file.ext yes/pseudo-netpath/seg/file.ext yes yes/ yes/ ../../../ ../ /a/g mid/6 ../../../ ../ ..yes/..yes ..yes/..yes/ ../../ ../../../ / ../../ ../../ yes/ yes/ yes/ yes/yes/ yes/yes yes/yes/ / /yes/ /yes/ /yes/ ../../ ../../ ..yes/ ..yes/ ..yes/ ..yes/..yes/ / /..yes/ /..yes/ /..yes/ / / / / / / / / / / / / / / / ../ ../ |
The test cases in section 2.2 Test Cases for
Canonicalization 1.1 are performed in the context
of XMLDSig as well. Here it should be noted that this is
performed in a different location (i.e. xmldsig/c14n11/) and the
XPath-Filter expression in the
ds:Transform/ds:XPath
should be equal to the
filter step of the XPath expressions in section 2.2 Test Cases for
Canonicalization 1.1 (cf.
explanation). The test cases are specified by an
"unsigned" ds:Signature
(without
ds:DigestValue
and
ds:SignatureValue
) in files in xmldsig/c14n11/ having the
postfix ...-template.xml
.
The set of test cases in this section test the
Reference Generation steps of [XMLDSIG2] and its rules that manage the
contents of the Transforms
element when
nodeset to octet-stream conversions are to be performed
by canonicalization.
General rules for these test cases:
Test cases contain a ds:Transforms
element with one child, containing a XPath filter
that depends on the test case.
| Test case xmldsig/defCan-1 | |
|---|---|
| Input details | The same input document as in section 2.2.4 Test Cases for xml:base attribute. |
| Rationale | Check that
implementations and APIs of [XMLDSIG2] honor the recommendation
to use [XML-C14N1.1] in
section 3.1.1 "Reference Generation" of [XMLDSIG2] and make its use
explicit as a ds:Transform . |
| Template | This template can be used to instruct some API to create a signature with a chain of transforms that would require implicit transformations from a node set to an octet stream. It is expected that c14n11 is inserted at the relevant places. |
| Signature |
<?xml version="1.0" encoding="UTF-8"?> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>\ + <Reference URI="c14n11/xml-base-input.xml"><Transforms>\ + <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">\ + <XPath xmlns:ietf="http://www.ietf.org">\ + ancestor-or-self::ietf:c14n11XmlBaseDoc1 and\ + not(ancestor-or-self::ietf:e2)</XPath></Transform>\ + <Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + </Transforms>\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>t7d2cL8Ink8A5i3cS9/bu9MBBU8=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>LR4s+Nxoq3VZO1NiCLoiovfCpK4=</SignatureValue>\ + </Signature> |
| Test case xmldsig/defCan-2 | |
|---|---|
| Input details | The same input document as in section 2.2.4 Test Cases for xml:base attribute. |
| Rationale | Check that
implementations and APIs of [XMLDSIG2] honor the recommendation
to use [XML-C14N1.1] in
section 3.1.1 "Reference Generation" of [XMLDSIG2] and make it's use
explicit as a ds:Transform . It is
expected that c14n11 is inserted at the relevant
places. |
| Template | This template can be used to instruct some API to create a signature with a chain of transforms that would require implicit transformations from a node set to an octet stream. The focus in this test case is to assure that c14n11 is inserted before transforms requiring an octet stream as input and also at the end of the chain of transforms if necessary because the last transform resulted in a node set. |
| Signature |
<?xml version="1.0" encoding="UTF-8"?> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>\ + <Reference URI="c14n11/xml-base-input.xml"><Transforms>\ + <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">\ + <XPath xmlns:ietf="http://www.ietf.org">\ + ancestor-or-self::ietf:e21</XPath></Transform>\ + <Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + <Transform Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116">\ + <xsl:stylesheet version="1.0"\ + xmlns="http://www.w3.org/1999/XSL/Transform"\ + xmlns:xsl="http://www.w3.org/1999/XSL/Transform">\ + <xsl:template match="@*|node()"><xsl:copy>\ + <xsl:apply-templates select="@*|node()"/></xsl:copy>\ + </xsl:template></xsl:stylesheet></Transform>\ + <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">\ + <XPath xmlns:ietf="http://www.ietf.org">1</XPath>\ + </Transform>\ + <Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + </Transforms>\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>fL7Igzs0LL7lKHJzAJIKYCphYBo=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>bKQLywY51VZwjutUX/CUMsVs6RE=</SignatureValue>\ + </Signature> |
| Test case xmldsig/defCan-3 | |
|---|---|
| Input details | The same input document as in section 2.2.4 Test Cases for xml:base attribute. |
| Rationale | Check that
implementations and APIs of [XMLDSIG2] honor the recommendation
to use [XML-C14N1.1] in
section 3.1.1 "Reference Generation" of [XMLDSIG2] and make it's use
explicit as a ds:Transform . It is
expected that c14n11 is inserted at the relevant
places. The focus in this test case is to assure
that c14n11 is inserted before transforms requiring
an octet stream as input but not inserted at the
end of the chain of transforms, which is not
necessary because the last transform resulted in an
octet stream. |
| Template | This template can be used to instruct some API to create a signature with a chain of transforms that would require implicit transformations from a node set to an octet stream. |
| Signature |
<?xml version="1.0" encoding="UTF-8"?> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>\ + <Reference URI="c14n11/xml-base-input.xml"><Transforms>\ + <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">\ + <XPath xmlns:ietf="http://www.ietf.org">\ + ancestor-or-self::ietf:e21</XPath></Transform>\ + <Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + <Transform Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116">\ + <xsl:stylesheet version="1.0"\ + xmlns="http://www.w3.org/1999/XSL/Transform"\ + xmlns:xsl="http://www.w3.org/1999/XSL/Transform">\ + <xsl:template match="@*|node()"><xsl:copy>\ + <xsl:apply-templates select="@*|node()"/></xsl:copy>\ + </xsl:template></xsl:stylesheet></Transform>\ + <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">\ + <XPath xmlns:ietf="http://www.ietf.org">1</XPath>\ + </Transform>\ + <Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + <Transform Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116">\ + <xsl:stylesheet version="1.0"\ + xmlns="http://www.w3.org/1999/XSL/Transform"\ + xmlns:xsl="http://www.w3.org/1999/XSL/Transform">\ + <xsl:template match="@*|node()"><xsl:copy>\ + <xsl:apply-templates select="@*|node()"/></xsl:copy>\ + </xsl:template></xsl:stylesheet></Transform>\ + </Transforms>\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>hqabUu4fEZp7GK5JRyFC26W5JBk=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>9+wp0W9xwL5X3kSttxABZ7p/kU0=</SignatureValue>\ + </Signature> |
This section defines test cases that test if implementations behave correctly when processing both schema-based xpointers and short-name xpointers with regards to comments present in the to be signed xml data object.
The following rules apply to the test cases in this section:
As the model processing is defined in [XMLDSIG2], the test cases are based
on XML signatures. For each test case, an XML
signature will be generated and validated. The
signatures will be enveloped signatures when the
URI
attribute is referencing the root
element and enveloping when the URI
attribute is referencing an element using its Id
attribute.
The input for the test cases is the to be signed
xml data object shown below and the
ds:Reference
's URI
attribute value (a schema-based xpointer or a
short-name pointer).
The ds:Reference
for enveloped
signatures will eventually contain two
Transform
elements, namely; the
enveloped signature transform and the conversion from
node set data to octet stream (canonical XML
1.1).
Below is the input document for the test cases in this section:
<?xml version="1.0" encoding="UTF-8"?> <ietf:c14n11XmlPointerDoc1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org" > \ + <!-- This is a xml document for checking behaviour of tools with\ + regards to comments when using scheme-based xpointers in the\ + ds:Reference's URI attribute --> <ietf:e1 xml:id="e1ID"> <!-- This is a comment for ietf:e1 element --> <ietf:e11 > <!-- This is a comment for ietf:e11 element --> <ietf:e111 /> </ietf:e11> <ietf:e12 at="2"> <!-- This is a comment for ietf:e12 element --> <ietf:e121 /> </ietf:e12> </ietf:e1> <ietf:e2 xml:id="e2ID"> <!-- This is a comment for ietf:e2 element --> <ietf:e21 /> </ietf:e2> <ietf:e3 xml:id="e3ID"> <ietf:e31 at="3"/> </ietf:e3> </ietf:c14n11XmlPointerDoc1> |
| Test case xmldsig/xpointer-1 | |
|---|---|
| Input details | The signature is an
enveloped signature. It appears as the last child
of the root element. The document enveloping the
signature is the one shown at the beginning of this
section. The value of the URI
attribute is "#xpointer(/)" (find it here). |
| Rationale | Check that implementations, following the rules stated in the [XMLDSIG2] model, dereference the URI getting the root element and its descendant, and that comments are preserved before proceeding with the computation of digest. |
| Signature |
<?xml version="1.0" encoding="UTF-8"?>\ + <ietf:c14n11XmlPointerDoc1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"> \ + <!-- This is a xml document for checking behaviour of tools with\ + regards to comments when using scheme-based xpointers in the\ + ds:Reference's URI attribute --> <ietf:e1 xml:id="e1ID"> <!-- This is a comment for ietf:e1 element --> <ietf:e11> <!-- This is a comment for ietf:e11 element --> <ietf:e111/> </ietf:e11> <ietf:e12 at="2"> <!-- This is a comment for ietf:e12 element --> <ietf:e121/> </ietf:e12> </ietf:e1> <ietf:e2 xml:id="e2ID"> <!-- This is a comment for ietf:e2 element --> <ietf:e21/> </ietf:e2> <ietf:e3 xml:id="e3ID"> <ietf:e31 at="3"/> </ietf:e3> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>\ + <Reference URI="#xpointer(/)"><Transforms>\ + <Transform\ + Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>\ + <Transform\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/>\ + </Transforms>\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>/IZyGLL72rXhisXRkB617TxJrL8=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>E4gxKwllVjvvlUQFe9p/ssO7Yxw=</SignatureValue>\ + </Signature></ietf:c14n11XmlPointerDoc1> |
| Test case xmldsig/xpointer-2 | |
|---|---|
| Input details | The signature is an
enveloping signature. The enveloped document is the
one shown at the beginning of this section. The
value of the URI attribute is
"#xpointer(id('e1ID'))" (find it here). |
| Rationale | Check that implementations, following the rules stated in the [XMLDSIG2] model, dereference the URI getting an element identified by its id attribute as well as its descendant, and that comments are preserved before proceeding with the computation of digest. |
| Signature |
<?xml version="1.0" encoding="UTF-8"?>\ + <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>\ + <Reference URI="#xpointer(id('e1ID'))"><Transforms>\ + <Transform\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/>\ + </Transforms>\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>XhSsDpWTt+ti0kcU9XYpleRDHfQ=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>brEpICVA4lg7eQwz7i/rlBmYXiU=</SignatureValue>\ + <Object>\ + <ietf:c14n11XmlPointerDoc1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"> \ + <!-- This is a xml document for checking behaviour of tools with\ + regards to comments when using scheme-based xpointers in the\ + ds:Reference's URI attribute --> <ietf:e1 xml:id="e1ID"> <!-- This is a comment for ietf:e1 element --> <ietf:e11> <!-- This is a comment for ietf:e11 element --> <ietf:e111/> </ietf:e11> <ietf:e12 at="2"> <!-- This is a comment for ietf:e12 element --> <ietf:e121/> </ietf:e12> </ietf:e1> <ietf:e2 xml:id="e2ID"> <!-- This is a comment for ietf:e2 element --> <ietf:e21/> </ietf:e2> <ietf:e3 xml:id="e3ID"> <ietf:e31 at="3"/> </ietf:e3> </ietf:c14n11XmlPointerDoc1></Object></Signature> |
| Test case xmldsig/xpointer-3 | |
|---|---|
| Input details | The signature is an
enveloped signature. It appears as the last child
of the root element. The document enveloping the
signature is the one shown at the beginning of this
section. The value of the URI
attribute is "". |
| Rationale | Check that implementations, following the rules stated in the [XMLDSIG2] model, dereference the URI getting the root element and its descendant, and that comments are not preserved before proceeding with the computation of digest. |
| Signature |
<?xml version="1.0" encoding="UTF-8"?>\ + <ietf:c14n11XmlPointerDoc1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"> \ + <!-- This is a xml document for checking behaviour of tools with\ + regards to comments when using scheme-based xpointers in the\ + ds:Reference's URI attribute --> <ietf:e1 xml:id="e1ID"> <!-- This is a comment for ietf:e1 element --> <ietf:e11> <!-- This is a comment for ietf:e11 element --> <ietf:e111/> </ietf:e11> <ietf:e12 at="2"> <!-- This is a comment for ietf:e12 element --> <ietf:e121/> </ietf:e12> </ietf:e1> <ietf:e2 xml:id="e2ID"> <!-- This is a comment for ietf:e2 element --> <ietf:e21/> </ietf:e2> <ietf:e3 xml:id="e3ID"> <ietf:e31 at="3"/> </ietf:e3> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>\ + <Reference URI=""><Transforms>\ + <Transform\ + Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>\ + <Transform\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/>\ + </Transforms>\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>gaV5r7qC3Ve/t641+d3ykN8JFSc=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>gS1QKSwAH/6eE3OFi/L9O0oKKig=</SignatureValue>\ + </Signature></ietf:c14n11XmlPointerDoc1> |
| Test case xmldsig/xpointer-4 | |
|---|---|
| Input details | The signature is an
enveloping signature. The enveloped document is the
one shown at the beginning of this section. The
value of the URI attribute is "#e1ID"
(find it here). |
| Rationale | Check that implementations, following the rules stated in the [XMLDSIG2] model, dereference the URI getting an element identified by its id attribute as well as its descendant, and that comments are not preserved before proceeding with the computation of digest. |
| Signature |
<?xml version="1.0" encoding="UTF-8"?>\ + <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>\ + <Reference URI="#e1ID"><Transforms>\ + <Transform\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/>\ + </Transforms>\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>3K+K4MbR2EW7l/ry59XockKqt4g=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>dgyjONUs9rBjW7PH25seGqcMNZY=</SignatureValue>\ + <Object>\ + <ietf:c14n11XmlPointerDoc1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"> \ + <!-- This is a xml document for checking behaviour of tools with\ + regards to comments when using scheme-based xpointers in the\ + ds:Reference's URI attribute --> <ietf:e1 xml:id="e1ID"> <!-- This is a comment for ietf:e1 element --> <ietf:e11> <!-- This is a comment for ietf:e11 element --> <ietf:e111/> </ietf:e11> <ietf:e12 at="2"> <!-- This is a comment for ietf:e12 element --> <ietf:e121/> </ietf:e12> </ietf:e1> <ietf:e2 xml:id="e2ID"> <!-- This is a comment for ietf:e2 element --> <ietf:e21/> </ietf:e2> <ietf:e3 xml:id="e3ID"> <ietf:e31 at="3"/> </ietf:e3> </ietf:c14n11XmlPointerDoc1></Object></Signature> |
| Test case xmldsig/xpointer-5 | |
|---|---|
| Input details | The signature is an
enveloping signature and signs three elements from
the document. The enveloped document is the one
shown at the beginning of this section. There are
three ds:Reference elements. For the
first one the value of the URI
attribute is "#xpointer(id('e1ID'))" (find it
here). For the second, it is
"#xpointer(id('e2ID'))" (find it
here). For the third one, it is
"#xpointer(id('e3ID'))" (find it
here). |
| Rationale | Check implementation's behaviour when processing several elements (with and without comments) referenced by its Id attribute using a schema-based xpointer. |
| Signature |
<?xml version="1.0" encoding="UTF-8"?>\ + <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>\ + <Reference URI="#xpointer(id('e1ID'))"><Transforms>\ + <Transform\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/>\ + </Transforms>\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>XhSsDpWTt+ti0kcU9XYpleRDHfQ=</DigestValue>\ + </Reference><Reference URI="#xpointer(id('e2ID'))">\ + <Transforms>\ + <Transform\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/>\ + </Transforms>\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>abyA1j4yzf1IgQLWwDwKuU9l8Ik=</DigestValue>\ + </Reference><Reference URI="#xpointer(id('e3ID'))">\ + <Transforms>\ + <Transform\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/>\ + </Transforms>\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>RUUBiUeFf8uRqTlpCyutkXDqnJ4=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>sG+0pHk9TB6v7jES9RZUIVKMFos=</SignatureValue>\ + <Object>\ + <ietf:c14n11XmlPointerDoc1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"> \ + <!-- This is a xml document for checking behaviour of tools with\ + regards to comments when using scheme-based xpointers in the\ + ds:Reference's URI attribute --> <ietf:e1 xml:id="e1ID"> <!-- This is a comment for ietf:e1 element --> <ietf:e11> <!-- This is a comment for ietf:e11 element --> <ietf:e111/> </ietf:e11> <ietf:e12 at="2"> <!-- This is a comment for ietf:e12 element --> <ietf:e121/> </ietf:e12> </ietf:e1> <ietf:e2 xml:id="e2ID"> <!-- This is a comment for ietf:e2 element --> <ietf:e21/> </ietf:e2> <ietf:e3 xml:id="e3ID"> <ietf:e31 at="3"/> </ietf:e3> </ietf:c14n11XmlPointerDoc1></Object></Signature> |
| Test case xmldsig/xpointer-6 | |
|---|---|
| Input details | The signature is an
enveloping signature and signs two elements from
the document. The enveloped document is the one
shown at the beginning of this section. There are
three ds:Reference elements. For the
first one the value of the URI
attribute is "#e1ID" (find it
here). For the second, it is "#e2ID" (find it
here). For the third one, it is "#e3ID" (find
it
here). |
| Rationale | Check implementation's behaviour when processing several elements (with and without comments) referenced by its Id attribute using a short-name xpointer. |
| Signature |
<?xml version="1.0" encoding="UTF-8"?>\ + <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>\ + <Reference URI="#e1ID"><Transforms>\ + <Transform\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/>\ + </Transforms>\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>3K+K4MbR2EW7l/ry59XockKqt4g=</DigestValue>\ + </Reference><Reference URI="#e2ID"><Transforms>\ + <Transform\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/>\ + </Transforms>\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>hnKFjGFr/jwLCCTckZpaclOwe28=</DigestValue>\ + </Reference><Reference URI="#e3ID"><Transforms>\ + <Transform\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/>\ + </Transforms>\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>RUUBiUeFf8uRqTlpCyutkXDqnJ4=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>XzEJQ+whhHUYlqiCEt8XFxC8wpk=</SignatureValue>\ + <Object>\ + <ietf:c14n11XmlPointerDoc1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"> \ + <!-- This is a xml document for checking behaviour of tools with\ + regards to comments when using scheme-based xpointers in the\ + ds:Reference's URI attribute --> <ietf:e1 xml:id="e1ID"> <!-- This is a comment for ietf:e1 element --> <ietf:e11> <!-- This is a comment for ietf:e11 element --> <ietf:e111/> </ietf:e11> <ietf:e12 at="2"> <!-- This is a comment for ietf:e12 element --> <ietf:e121/> </ietf:e12> </ietf:e1> <ietf:e2 xml:id="e2ID"> <!-- This is a comment for ietf:e2 element --> <ietf:e21/> </ietf:e2> <ietf:e3 xml:id="e3ID"> <ietf:e31 at="3"/> </ietf:e3> </ietf:c14n11XmlPointerDoc1></Object></Signature> |
This Working group has identified a number of differences between [RFC-4514] and [RFC-2253]. They are described in this e-mail within the XML Security Specifications Maintenance Working Group e-mail list archive. This section contains test cases designed for checking that applications can parse and generate RFC 4514 Distinguished Names with these differences.
The following rules apply for the test cases defined in this section:
The input to each test case is an XML Signature. Each signature contains an X509SubjectName or X509IssuerSerial element with an RFC 4514 Distinguished Name.
To resolve the key, the application must find a certificate containing a matching issuer/serial or subject DN from the certificates that are contained in the "certs" directory.
Signature generation is also required. A PKCS#12 KeyStore containing the private keys used to generate the signatures is in the file "certs/keystore.p12". The keystore password is "secret". The key entry name is the same as the corresponding certificate file name (without the ".crt" part).
| Test case xmldsig/dname/diffRFCs-1 | |
|---|---|
| Input details | The input is an XML Signature containing an X509SubjectName in RFC 4514 format. The DN contains at least one Relative Distinguished Name whose attribute type keyword is encoded with one alphabetic character, and another Relative Distinguished Name whose attribute type keyword is encoded with two characters. |
| Rationale | Check processing of attribute type keywords by tools implementing [RFC-4514]. |
| [RFC-4514] DN | CN=John,C=US |
| Signature |
<?xml version="1.0" encoding="UTF-8" standalone="no"?>\ + <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>\ + <Reference URI="#object">\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>nxGVxTzX3uQVeaZ7vtWMLc+V6CE=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>\ + DOz4KhJHOvhzPiKjxl0WVsrXPuZ9XQtdDvKN0KuLQGIzXkljfkFEQA==</SignatureValue>\ + <KeyInfo><X509Data>\ + <X509SubjectName>CN=John,C=US</X509SubjectName>\ + </X509Data></KeyInfo>\ + <Object Id="object">Approved</Object></Signature> |
| Test case xmldsig/dname/diffRFCs-2 | |
|---|---|
| Input details | The input is an XML Signature containing an X509SubjectName in RFC 4514 format. The DN contains at least a Relative Distinguished Name containing space characters. [RFC-2253] does not allow escaping, whereas [RFC-4514] requires space characters to be escaped. |
| Rationale | Check escaping of space characters by tools implementing [RFC-4514]. |
| [RFC-4514] DN | CN=\ Spacey\ ,C=US |
| Signature |
<?xml version="1.0" encoding="UTF-8" standalone="no"?>\ + <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>\ + <Reference URI="#object">\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>nxGVxTzX3uQVeaZ7vtWMLc+V6CE=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>\ + V18nxls1pqn4IyA/GNosGfqLHEE6INnyuV9TmHlYt/sYsaagHCH9Xw==</SignatureValue>\ + <KeyInfo><X509Data>\ + <X509SubjectName>CN=\ Spacey\ ,C=US</X509SubjectName>\ + </X509Data></KeyInfo>\ + <Object Id="object">Approved</Object></Signature> |
| Test case xmldsig/dname/diffRFCs-3 | |
|---|---|
| Input details | The input is an XML Signature containing an X509SubjectName in RFC 4514 format. The DN contains at least a Relative Distinguished Name containing null characters. [RFC-2253] does not allow escaping, whereas [RFC-4514] requires space characters to be escaped. |
| Rationale | Check escaping of null characters by tools implementing [RFC-4514]. |
| [RFC-4514] DN | CN=\00,C=US |
| Signature |
<?xml version="1.0" encoding="UTF-8" standalone="no"?>\ + <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>\ + <Reference URI="#object">\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>nxGVxTzX3uQVeaZ7vtWMLc+V6CE=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>\ + N6jHpYnYpggrfADJkvZfggCaUq9dzU9M3EQ+27wA8f92nWwmrlyUQQ==</SignatureValue>\ + <KeyInfo><X509Data>\ + <X509SubjectName>CN=\00,C=US</X509SubjectName>\ + </X509Data></KeyInfo>\ + <Object Id="object">Approved</Object></Signature> |
| Test case xmldsig/dname/diffRFCs-4 | |
|---|---|
| Input details | The input is an XML Signature containing an X509SubjectName in RFC 4514 format. The DN contains at least a Relative Distinguished Name containing a non-leading number sign character that is not escaped. [RFC-2253] requires escaping of non-leading number sign characters, whereas [RFC-4514] does not. |
| Rationale | Check processing of non-leading number sign characters that are not escaped by tools implementing [RFC-4514]. |
| [RFC-4514] DN | CN=Num#ber,C=US |
| Signature |
<?xml version="1.0" encoding="UTF-8" standalone="no"?>\ + <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>\ + <Reference URI="#object">\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>nxGVxTzX3uQVeaZ7vtWMLc+V6CE=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>\ + QN8dVUz4674CG7tnHJ+VSDFKbttZ3Ywa5rizoYS2EGUD8/33RFlZJA==</SignatureValue>\ + <KeyInfo><X509Data>\ + <X509SubjectName>CN=Num#ber,C=US</X509SubjectName>\ + </X509Data></KeyInfo>\ + <Object Id="object">Approved</Object></Signature> |
| Test case xmldsig/dname/diffRFCs-5 | |
|---|---|
| Input details | The input is an XML Signature containing an X509SubjectName in RFC 4514 format. The DN contains at least a Relative Distinguished Name containing an equals sign character that is not escaped. [RFC-2253] requires escaping of equals sign characters, whereas [RFC-4514] does not. |
| Rationale | Check processing of equals sign characters that are not escaped by tools implementing [RFC-4514]. |
| [RFC-4514] DN | CN=Eq=uals,C=US |
| Signature |
<?xml version="1.0" encoding="UTF-8" standalone="no"?>\ + <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>\ + <Reference URI="#object">\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>nxGVxTzX3uQVeaZ7vtWMLc+V6CE=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>\ + TEFSu5hmr8r5JU78U9MgS0mdZIZOXUjORTRzDFaBWh9DhFjPjxxW4w==</SignatureValue>\ + <KeyInfo><X509Data>\ + <X509SubjectName>CN=Eq=uals,C=US</X509SubjectName>\ + </X509Data></KeyInfo>\ + <Object Id="object">Approved</Object></Signature> |
The set of test cases in this section are designed to test the representation of Distinguished Names as Strings as specified by [RFC-4514].
The same rules defined in section <IP_ADDRESS> apply to the test cases in this section.
| Test case xmldsig/dname/dnString-4 | |
|---|---|
| Input details |
The DistinguishedName has the following
restrictions:
|
| Rationale | Check that implementations correctly manage escaping of trailing space characters. |
| [RFC-4514] DN | CN=Trailing\20\20,C=US |
| Signature |
<?xml version="1.0" encoding="UTF-8" standalone="no"?>\ + <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>\ + <Reference URI="#object">\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>nxGVxTzX3uQVeaZ7vtWMLc+V6CE=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>\ + ONd8OoOnv9OThyiTPkneEcsdgVt65w6AgUAxidekHeKmjyQxnYEdWA==</SignatureValue>\ + <KeyInfo><X509Data>\ + <X509SubjectName>CN=Trailing\20\20,C=US</X509SubjectName>\ + </X509Data></KeyInfo>\ + <Object Id="object">Approved</Object></Signature> |
| Test case xmldsig/dname/dnString-6 | |
|---|---|
| Input details |
The DistinguishedName has the following
restrictions:
|
| Rationale | Check that implementations correctly manage escaping of an ASCII control character that is neither the first nor the final character of the group. |
| [RFC-4514] DN | CN=Con\09trol,C=US |
| Signature |
<?xml version="1.0" encoding="UTF-8" standalone="no"?>\ + <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>\ + <Reference URI="#object">\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>nxGVxTzX3uQVeaZ7vtWMLc+V6CE=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>\ + V34pKGIfKacwJtTEShfSXx4M2dhSOTqZVCIL6nO66lm+JTQ//wCKaA==</SignatureValue>\ + <KeyInfo><X509Data>\ + <X509SubjectName>CN=Con\09trol,C=US</X509SubjectName>\ + </X509Data></KeyInfo>\ + <Object Id="object">Approved</Object></Signature> |
| Test case xmldsig/dname/dnString-8 | |
|---|---|
| Input details |
The DistinguishedName has the following
restrictions:
|
| Rationale | Check that implementations correctly manage escaping of all the special characters (except '"', 'lt;' and '>').. |
| [RFC-4514] DN | CN=E\+s\,c\;aped,C=US |
| Signature |
<?xml version="1.0" encoding="UTF-8" standalone="no"?>\ + <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>\ + <Reference URI="#object">\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>nxGVxTzX3uQVeaZ7vtWMLc+V6CE=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>\ + L2r+QCiO0qOPgDYybThQEbP7A8Iq8AomDGBXgQqe4mkuLMnroTxnGA==</SignatureValue>\ + <KeyInfo><X509Data>\ + <X509SubjectName>CN=E\+s\,c\;aped,C=US</X509SubjectName>\ + </X509Data></KeyInfo>\ + <Object Id="object">Approved</Object></Signature> |


HackDays
Open challenges
Random text
Challenege title
Fake data goes here
Closed challenges
Random text
Challenege title
Fake data goes here


If you have Combination Skin:
-any of the above products should work for you but combo skin is really just code for your ability to use
both oil and dry skin items
-luckily for you lots of youtubers and beauty bloggers have found a new way to use clay face masks, you
can put a clay mask on blemishes while using a moisterizing mask on dry patches. It's really about finding
what works for you.


--- layout: page title: BIXI Bikeshare Project subtitle: Welcome to our Applied Data Analysis final project! use-site-title: true ---
Our project on data analysis for social good focuses on the bikeshare system in Montreal and how we can improve the system using data analysis in order to encourage bike travel as a mode of transport. Bikes are both more environmentally friendly and healthy than other modes of transport such as cars and buses. By adapting the bikeshare system to better suit the needs of the users we can encourage bike travel and improve transport experiences which are such an integral part of our everyday lives.
{% if paginator.total_pages > 1 %}


CS5346 Information Visualization
Go back to home
Hourly Comments by Days
The total commits per working hour (8:00am - 6:00pm) of each day (Monday to Sunday)
Generate Graph


Toggle navigation
AngularJS
Blog
Demo
AngularJS Tutorials
View on Github
Set to unsorted
Sort By Title
Sort By Author
{{item.title}}
Go to Tutorial
By: {{item.author}}


Take a look around cosy new Christmas bar, Thor's Tipi Wooden benches, faux-fur rugs, a roaring firepit and plenty of 'hygge' 15 Nov 2019, 12:55 by Rachel Gorman Inside Trinity Square's new Christmas bar, Thor's Tipi, Nottingham(Image: Rachel Gorman) Inside Trinity Square's new Christmas bar, Thor's Tipi, Nottingham(Image: Rachel Gorman) Inside Trinity Square's new Christmas bar, Thor's Tipi, Nottingham(Image: Rachel Gorman) Inside Trinity Square's new Christmas bar, Thor's Tipi, Nottingham(Image: Rachel Gorman) Inside Trinity Square's new Christmas bar, Thor's Tipi, Nottingham(Image: Rachel Gorman) Inside Trinity Square's new Christmas bar, Thor's Tipi, Nottingham(Image: Rachel Gorman) Inside Trinity Square's new Christmas bar, Thor's Tipi, Nottingham(Image: Rachel Gorman) Inside Trinity Square's new Christmas bar, Thor's Tipi, Nottingham(Image: Rachel Gorman) Inside Trinity Square's new Christmas bar, Thor's Tipi, Nottingham. Pictured: manager Marie Stafford(Image: Rachel Gorman) Inside Trinity Square's new Christmas bar, Thor's Tipi, Nottingham(Image: Rachel Gorman) Inside Trinity Square's new Christmas bar, Thor's Tipi, Nottingham(Image: Rachel Gorman) Inside Trinity Square's new Christmas bar, Thor's Tipi, Nottingham. Pictured: manager Marie Stafford(Image: Rachel Gorman) Inside Trinity Square's new Christmas bar, Thor's Tipi, Nottingham(Image: Rachel Gorman)


XCO
Protections
Clothing
Bikes
Downhill
Protections
Clothing
Bikes
Road
Protections
Clothing
Bikes
Cyclocross
Protections
Clothing
Bikes
{{#usuario}}
{{name}} ,{{full_name}}
{{/usuario}} {{^usuario}}
Login/register
Sign In
Forgot password?
Remember me
Username & password don't match!
Register
{{/usuario}}
Shopping Cart
{{countItems}}
Payment Methods


6am
7am
8am
9am
10am
11am
12pm
1pm
2pm
3pm
4pm
5pm
6pm
7pm
Total
City
Minimum Customers
Max Customers
Average Customers
Salmon Cookies
welcome to our site
we are a salmon based cookie company


if (log.length) { ?>
= log[0].team_name ?> sent email log: |
Email Type |
Name |
Email Address |
Subject |
Timestamp |
log.forEach( function (e) { ?>
var ts = utils().date.format("logs", new Date(e.timestamp)); ?>
| = e.email_type ?> |
= e.first_name ?> |
= e.email_address ?> |
= e.subject ?> |
= ts ?> |
}) ?>
} else { ?>
No emails have been sent since the last log check |
} ?>
|


|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
public interface ModeCorrelationUI
This interface declares basic functionality for the user interface of a
JModeCorrelationPanel
. This interface tries to follow the structure
described in Swing for a Model-View-Controller. Generally, the
JModeCorrelationPanel
is instantiated and then a
ModeCorelationUI
is installed onto it. Any implementing classes of
this interface must be able to add and remove their own layout, components,
listeners, keyboard actions, and defaults. If the user interface is not
completely uninstalled when called, it can lead to unpredictable results in
the JModeCorrelationPanel
.
| Field Summary | |
|---|---|
static int |
ERROR_MESSAGE
A constant for an error message |
static int |
WARNING_MESSAGE
A constant for a warning message |
| Method Summary | |
|---|---|
java.lang.String |
getConnectionOutput()
Returns the mode connection output file name. |
java.lang.String |
getCorrelationOutput()
Returns the mode correlation output file name. |
double |
getLowerTolerance()
Returns the current mode correlation lower tolerance. |
java.lang.String |
getMassInput()
Returns the mass matrix input file name. |
double |
getUpperTolerance()
Returns the current mode correlation upper tolerance. |
void |
installUI(JModeCorrelationPanel correlationPanel)
Installs layout, components, listeners, keyboard actions, defaults, and initializes any values or fields. |
void |
setConnectionOutput(java.lang.String fileName)
Replaces the mode connection output file with the given one. |
void |
setCorrelationOutput(java.lang.String fileName)
Replaces the mode correlation output file with the given one. |
void |
setLowerTolerance(double lowerTolerance)
Replaces the mode correlation lower tolerance with the given one. |
void |
setMassInput(java.lang.String fileName)
Replaces the mass matrix input file with the given one. |
void |
setUpperTolerance(double upperTolerance)
Replaces the mode correlation upper tolerance with the given one. |
java.lang.String |
showConnectionSaveDialog()
Shows a file chooser dialog for the supported mode connection output file types and returns the selected file. |
java.lang.String |
showCorrelationSaveDialog()
Shows a file chooser dialog for the supported mode correlation output file types and returns the selected file. |
java.lang.String |
showMassOpenDialog()
Shows a file chooser dialog for the supported mass matrix input file types and returns the selected file. |
void |
showMessageDialog(java.lang.Object message,
java.lang.String title,
int messageType)
Shows a message dialog for error or warning messages. |
void |
uninstallUI(JModeCorrelationPanel correlationPanel)
Uninstalls layout, components, listeners, keyboard actions, and defaults. |
| Field Detail |
|---|
static final int ERROR_MESSAGE
static final int WARNING_MESSAGE
| Method Detail |
|---|
java.lang.String getConnectionOutput()
java.lang.String getCorrelationOutput()
java.lang.String getMassInput()
double getLowerTolerance()
double getUpperTolerance()
void installUI(JModeCorrelationPanel correlationPanel)
correlationPanel
- the JModeCorrelationPanel
where the
user interface will be installedvoid setConnectionOutput(java.lang.String fileName)
fileName
- the new mode connection output file namevoid setCorrelationOutput(java.lang.String fileName)
fileName
- the new mode correlation output file namevoid setLowerTolerance(double lowerTolerance)
lowerTolerance
- the new mode correlation lower tolerancevoid setMassInput(java.lang.String fileName)
fileName
- the new mass matrix input file namevoid setUpperTolerance(double upperTolerance)
upperTolerance
- the new mode correlation upper tolerancejava.lang.String showConnectionSaveDialog()
java.lang.String showCorrelationSaveDialog()
java.lang.String showMassOpenDialog()
void showMessageDialog(java.lang.Object message, java.lang.String title, int messageType)
message
- the message of the error or warningtitle
- the title of the error or warningmessageType
- an ERROR_MESSAGE
or WARNING_MESSAGE
void uninstallUI(JModeCorrelationPanel correlationPanel)
correlationPanel
- the JModeCorrelationPanel
where the
user interface will be uninstalled
|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |


Welcome to JSChannel
Prerequisites for ng-workshop:
- Chrome/Firefox + Firebug
- Any text editor
Functional Reactive Programming
6 June 2015 |
@Pykih |
51 RSVPs
FRP 2 coming soon!
- Since 2013
- Around 30 Meetups
- 3 Conferences
- Next conference on 17 - 18 July, 2015
- Sole member of JSConf family in India
- Follow us on Twitter @js_channel
Discount code for you all:
JSC-MUM
JSChannel
Platform for everyone!
Agenda:
- Enterprise/Large Scale JavaScript App Development (1hr)
- AngularJS Basics Workshop (1hr30m)
- Q&A (30m)


Last updated March 2021
The information provided by Gas Pump App LLC ("we," "us" or "our") on Gas Pump (the "App") is for general informational purposes only. All information on the App is provided in good faith, however we make no representation or warranty of any kind, express or implied, regarding the accuracy, adequacy, validity, reliability, availability or completeness of any information on the App. UNDER NO CIRCUMSTANCE SHALL WE HAVE ANY LIABILITY TO YOU FOR ANY LOSS OR DAMAGE OF ANY KIND INCURRED AS A RESULT OF THE USE OF THE APP OR RELIANCE ON ANY INFORMATION PROVIDED ON THE APP.


{{ event.org.name }} presents {{ event.movie.title.international }} by {{ event.movie.directors | displayName }} Screening now Play


Here is a
paragraph
that requires
word wrap
First
item
Second
item
Thrid item
Hello World
Example SVG text 1
Text along a curved path...


We optimize bitcoin!
- target holistic models
- redefine world-class mindshare
- leverage web-enabled systems
- aggregate e-business architectures
- facilitate front-end niches
- innovate back-end e-services
- harness cutting-edge convergence
- redefine global portals
- grow efficient technologies
- reintermediate B2C methodologies
- facilitate mission-critical architectures
- repurpose B2B bandwidth
- facilitate B2B markets


|
Kinova_API
v5.02.00
ROS communication with Kinova API
|
Public Member Functions | |
| KinovaComm (const ros::NodeHandle &node_handle, boost::recursive_mutex &api_mutex, const bool is_movement_on_start) | |
| void | stopAPI () |
| void | startAPI () |
| bool | isStopped () |
| void | startForceControl () |
| void | stopForceControl () |
| int | robotType () const |
| void | getQuickStatus (QuickStatus &quick_status) |
| void | getConfig (ClientConfigurations &config) |
| void | setConfig (const ClientConfigurations &config) |
| void | printConfig (const ClientConfigurations &config) |
| void | getControlType (int &controlType) |
| void | getGeneralInformations (GeneralInformations &general_info) |
| void | getSensorsInfo (SensorsInfo &sensor_Info) |
| void | getForcesInfo (ForcesInfo &force_Info) |
| void | getGripperStatus (Gripper &gripper_status) |
| void | setAngularControl () |
| void | getAngularCommand (AngularPosition &angular_command) |
| void | getJointAngles (KinovaAngles &angles) |
| void | setJointAngles (const KinovaAngles &angles, int timeout=0, bool push=true) |
| void | getJointVelocities (KinovaAngles &vels) |
| void | setJointVelocities (const AngularInfo &joint_vel) |
| void | getJointAccelerations (AngularAcceleration &joint_acc) |
| void | getJointTorques (KinovaAngles &tqs) |
| void | getJointCurrent (AngularPosition &anguler_current) |
| void | setJointTorqueMinMax (AngularInfo &min, AngularInfo &max) |
| void | printAngles (const KinovaAngles &angles) |
| void | setCartesianControl () |
| void | getCartesianCommand (CartesianPosition &cartesian_command) |
| void | getCartesianPosition (KinovaPose &position) |
| void | setCartesianPosition (const KinovaPose &position, int timeout=0, bool push=true) |
| void | setCartesianVelocities (const CartesianInfo &velocities) |
| float | getMaxTranslationVelocity (void) |
| void | setMaxTranslationVelocity (const float &max_trans_vel) |
| float | getMaxOrientationVelocity (void) |
| void | setMaxOrientationVelocity (const float &max_orient_vel) |
| void | getCartesianForce (KinovaPose &position) |
| void | setCartesianForceMinMax (const CartesianInfo &min, const CartesianInfo &max) |
| void | setCartesianInertiaDamping (const CartesianInfo &inertia, const CartesianInfo &damping) |
| void | printPosition (const KinovaPose &position) |
| void | getUserCommand (UserPosition &user_position) |
| void | getGlobalTrajectoryInfo (TrajectoryFIFO &trajectoryFIFO) |
| void | eraseAllTrajectories (void) |
| int | numFingers () const |
| void | getFingerPositions (FingerAngles &fingers) |
| void | setFingerPositions (const FingerAngles &fingers, int timeout=0, bool push=true) |
| void | printFingers (const FingersPosition &fingers) |
| void | homeArm (void) |
| bool | isHomed (void) |
| void | initFingers (void) |
| void | setEndEffectorOffset (unsigned int status, float x, float y, float z) |
| void | getEndEffectorOffset (unsigned int &status, float &x, float &y, float &z) |
| bool kinova::KinovaComm::isStopped | ( | ) |
check if API lost the control of robot.
| void kinova::KinovaComm::startForceControl | ( | ) |
This function activates the reactive force control for admittance control. Admittance control may be applied to joint or Cartesian depending to the control mode.
| int kinova::KinovaComm::robotType | ( | ) | const |
get robotType Index for robot type: JACOV1_ASSISTIVE = 0, MICO_6DOF_SERVICE = 1, MICO_4DOF_SERVICE = 2, JACOV2_6DOF_SERVICE = 3, JACOV2_4DOF_SERVICE = 4, MICO_6DOF_ASSISTIVE = 5, JACOV2_6DOF_ASSISTIVE = 6,
| void kinova::KinovaComm::getQuickStatus | ( | QuickStatus & | quick_status | ) |
This function gets information regarding some status flag of the robotical arm.
| quick_status | This structure holds various informations but mostly it is flag status, such as robotype, retractType, forceControlStatus, |
| void kinova::KinovaComm::getConfig | ( | ClientConfigurations & | config | ) |
obtain the current client configuration.
| config | This structure holds informations relative to the client, including serial number, robot model, limits for position, velocity, acceleration and force, etc. |
| void kinova::KinovaComm::setConfig | ( | const ClientConfigurations & | config | ) |
This function set the client configurations of the robotical arm. The configuration data is stored on the arm itself.
| config | config This structure holds informations relative to the client, including serial number, robot model, limits for position, velocity, acceleration and force, etc. |
| void kinova::KinovaComm::printConfig | ( | const ClientConfigurations & | config | ) |
Dumps the client configuration onto the screen.
| config | This structure holds informations relative to the client, including serial number, robot model, limits for position, velocity, acceleration and force, etc. |
| void kinova::KinovaComm::getControlType | ( | int & | controlType | ) |
get current control type The control in ROS is independent to Joystick control type. For example: even set robot in joint control though api in ROS, robot may still controlled in joint level by joystick.
| controlType | Cartesian control[0] or joint control[1] |
| void kinova::KinovaComm::getGeneralInformations | ( | GeneralInformations & | general_info | ) |
get almost all information of the robotical arm.
| general_info | includes: power statistics, sensor infos, robot position and command, etc. |
| void kinova::KinovaComm::getSensorsInfo | ( | SensorsInfo & | sensor_Info | ) |
This function returns information about the robotical arm's sensors. (Voltage, Total current, Temperature, acceleration)
| The | structure containing the sensor's informations |
| void kinova::KinovaComm::getForcesInfo | ( | ForcesInfo & | force_Info | ) |
This function gets information regarding all forces.
| force_Info | A struct containing the information about the forces. Joint torque and end-effector wrench in Nm and N. |
| void kinova::KinovaComm::getGripperStatus | ( | Gripper & | gripper_status | ) |
This function gets informations about the robotical arm's gripper. Some information may be missing, it is still in development.
| gripper_status | A struct containing the information of the gripper. Most information of each fingers, including model, motion, force, limits, etc. |
| void kinova::KinovaComm::getAngularCommand | ( | AngularPosition & | angular_command | ) |
This function get the angular command of all actuators.
| An | AngularPosition struct containing the values. Units are degrees. angular_command {AngularInfo, FingersPosition} |
| void kinova::KinovaComm::getJointAngles | ( | KinovaAngles & | angles | ) |
This function returns the angular position of the robotical arm's end effector.
| angles | A structure that contains the position of each actuator. Unit in degrees. |
| void kinova::KinovaComm::setJointAngles | ( | const KinovaAngles & | angles, |
| int | timeout = 0 , |
||
| bool | push = true |
||
| ) |
Sends a joint angle command to the Kinova arm. This function sends trajectory point(Angular) that will be added in the robotical arm's FIFO. Waits until the arm has stopped moving before releasing control of the API. sendAdvanceTrajectory() is called in api to complete the motion.
| angles | target joint angle to set, type float, unit in degree |
| timeout | default value 0.0, not used. |
| push | default true, errase all trajectory before request motion.. |
| void kinova::KinovaComm::getJointVelocities | ( | KinovaAngles & | vels | ) |
This function get the velocity of each actuator.
| vels | A kinovaAngles structure contains joint velocity of each actuator. Unit in degrees/second. |
| void kinova::KinovaComm::setJointVelocities | ( | const AngularInfo & | joint_vel | ) |
This function controls robot with joint velocity. This function sends trajectory point(ANGULAR_VELOCITY) that will be added in the robotical arm's FIFO. Waits until the arm has stopped moving before releasing control of the API. sendAdvanceTrajectory() is called in api to complete the motion.
| joint_vel | joint velocity in degree/second |
| void kinova::KinovaComm::getJointAccelerations | ( | AngularAcceleration & | joint_acc | ) |
This function get the accelerometer values of each actuator. It does not directly refer to the angular acceleration.
| joint_acc | An AngularAcceleration struct containing the values. Units are in G |
| void kinova::KinovaComm::getJointTorques | ( | KinovaAngles & | tqs | ) |
This function returns the torque of each actuator.
| tqs | A structure that contains the torque of each actuator. Unit is Newton * meter |
| void kinova::KinovaComm::getJointCurrent | ( | AngularPosition & | anguler_current | ) |
This function returns the current that each actuator consume on the main supply.
| anguler_current | A structure that contains the current of each actuator and finger. Unit in A. |
| void kinova::KinovaComm::setJointTorqueMinMax | ( | AngularInfo & | min, |
| AngularInfo & | max | ||
| ) |
This function set the angular torque's maximum and minimum values.
| min | A struct that contains all angular minimum values. (Unit: N * m) |
| max | 6 A struct that contains all angular max values. (Unit: N * m) |
| void kinova::KinovaComm::printAngles | ( | const KinovaAngles & | angles | ) |
Dumps the current joint angles onto the screen.
| angles | A structure contains six joint angles. Unit in degrees |
| void kinova::KinovaComm::getCartesianCommand | ( | CartesianPosition & | cartesian_command | ) |
This function get the cartesian command of the end effector. The Cartesian orientation is expressed in Euler-ZYX convention, so that tf::Matrix3x3 EulerYPR = Rz(tz)*Ry(ty)*Rx(tx)
| cartesian_command | An CartesianPosition struct containing the values of end-effector and fingers. |
| Member | Unit |
|---|---|
| X | meter |
| Y | meter |
| Z | meter |
| Theta X | RAD |
| Theta Y | RAD |
| Theta Z | RAD |
| Finger 1 | No unit |
| Finger 2 | No unit |
| Finger 3 | No unit |
| void kinova::KinovaComm::getCartesianPosition | ( | KinovaPose & | position | ) |
This function returns the cartesian position of the robotical arm's end effector. In KinovaPose, orientation is expressed in Euler-ZYX convention, so that tf::Matrix3x3 EulerYPR = Rz(tz)*Ry(ty)*Rx(tx)
| position | pose in [X,Y,Z,ThetaX,ThetaY,ThetaZ] form, Units in meters and radians. |
| void kinova::KinovaComm::setCartesianPosition | ( | const KinovaPose & | pose, |
| int | timeout = 0 , |
||
| bool | push = true |
||
| ) |
Sends a cartesian coordinate trajectory to the Kinova arm. This function sends trajectory point(Cartesian) that will be added in the robotical arm's FIFO. Waits until the arm has stopped moving before releasing control of the API. sendBasicTrajectory() is called in api to complete the motion. In KinovaPose, orientation is expressed in Euler-ZYX convention, so that tf::Matrix3x3 EulerYPR = Rz(tz)*Ry(ty)*Rx(tx)
| pose | target pose of robot [X,Y,Z, ThetaX, ThetaY, ThetaZ], unit in meter and radians. |
| timeout | default 0.0, not used. |
| push | default true, errase all trajectory before request motion.. |
| void kinova::KinovaComm::setCartesianVelocities | ( | const CartesianInfo & | velocities | ) |
Linear and angular velocity control in Cartesian space This function sends trajectory point(CARTESIAN_VELOCITY) that will be added in the robotical arm's FIFO. Waits until the arm has stopped moving before releasing control of the API. sendAdvanceTrajectory() is called in api to complete the motion. Definition of angular velocity "Omega" is based on the skew-symmetric matrices "S = R*R^(-1)", where "R" is the rotation matrix. angular velocity vector "Omega = [S(3,2); S(1,3); S(2,1)]".
| velocities | unit are meter/second for linear velocity and radians/second for "Omega". |
| float kinova::KinovaComm::getMaxTranslationVelocity | ( | void | ) |
This function returns the max translation(X, Y and Z) velocity of the robot's end effector in ClientConfigurations.
| void kinova::KinovaComm::setMaxTranslationVelocity | ( | const float & | max_trans_vel | ) |
This function set the max translation(X, Y and Z) velocity of the robot's end effector in ClientConfigurations.
| max_trans_vel | Unit in meter per second |
| float kinova::KinovaComm::getMaxOrientationVelocity | ( | void | ) |
This function get max orientation(ThetaX, ThetaY and ThetaZ) velocity of the robot's end effector. Definition of angular velocity "Omega" is based on the skew-symmetric matrices "S = R*R^(-1)", where "R" is the rotation matrix. angular velocity vector "Omega = [S(3,2); S(1,3); S(2,1)]".
| void kinova::KinovaComm::setMaxOrientationVelocity | ( | const float & | max_orient_vel | ) |
This function set max orientation(ThetaX, ThetaY and ThetaZ) velocity of the robot's end effector. Definition of angular velocity "Omega" is based on the skew-symmetric matrices "S = R*R^(-1)", where "R" is the rotation matrix. angular velocity vector "Omega = [S(3,2); S(1,3); S(2,1)]".
| max_orient_vel | Unit in rad/second |
| void kinova::KinovaComm::getCartesianForce | ( | KinovaPose & | cart_force | ) |
This function returns the cartesian wrench at the robotical arm's end effector.
| cart_force | A structure that contains the wrench vector at the end effector. Unit in N and N * m. |
| void kinova::KinovaComm::setCartesianForceMinMax | ( | const CartesianInfo & | min, |
| const CartesianInfo & | max | ||
| ) |
This function set the Cartesian force's maximum and minimum values.
| min | A struct that contains all Cartesian minimum values. (Translation unit: N Orientation unit: N * m) |
| max | A struct that contains all Cartesian maximum values. (Translation unit: N Orientation unit: N * m) |
| void kinova::KinovaComm::setCartesianInertiaDamping | ( | const CartesianInfo & | inertia, |
| const CartesianInfo & | damping | ||
| ) |
This function set the Cartesian inertia and damping value.
| inertia | A struct that contains all Cartesian inertia values. (Translation unit: Kg, Orientation unit: Kg * m^2) |
| damping | A struct that contains all Cartesian damping values. (Translation unit: (N * s) / m, Orientation unit: (N * s) / RAD) |
| void kinova::KinovaComm::printPosition | ( | const KinovaPose & | position | ) |
Dumps the current cartesian pose onto the screen. In KinovaPose, orientation is expressed in Euler-ZYX convention, so that tf::Matrix3x3 EulerYPR = Rz(tz)*Ry(ty)*Rx(tx)
| position | in [X,Y,Z,ThetaX,ThetaY,ThetaZ], where orientation is using Euler-ZYX convention. |
| void kinova::KinovaComm::getUserCommand | ( | UserPosition & | user_position | ) |
This function extract the UserPosition from trajectory.
| user_position | contains POSITION_TYPE(Angular/Cartesian position/velocity, etc), CartesianInfo and AngularInfo, finger positions etc. |
| void kinova::KinovaComm::getGlobalTrajectoryInfo | ( | TrajectoryFIFO & | trajectoryFIFO | ) |
This function returns informations about the trajectories FIFO stored inside the robotical arm. Detail of trajectory point is not stored in trajectoryFIFO.
| trajectoryFIFO | The structure containing the FIFO's informations: {TrajectoryCount; UsedPercentage; MaxSize}. |
| int kinova::KinovaComm::numFingers | ( | ) | const |
This function get number of fingers. number of fingers determined by robotType. 3 fingers for robotType(0,3,4,6) and 2 fingers for robotType(1,2,5)
| void kinova::KinovaComm::getFingerPositions | ( | FingerAngles & | fingers | ) |
This function obtain the joint position of fingers.
| fingers | in degrees, range from 0 to 6800 |
| void kinova::KinovaComm::setFingerPositions | ( | const FingerAngles & | fingers, |
| int | timeout = 0 , |
||
| bool | push = true |
||
| ) |
This function sets the finger positions The new finger position, combined with current joint values are constructed as a trajectory point. sendAdvancedTrajectory() is called in api to complete the motion.
| fingers | in degrees from 0 to about 6800 |
| timeout | timeout default 0.0, not used. |
| push | default true, errase all trajectory before request motion. |
| void kinova::KinovaComm::printFingers | ( | const FingersPosition & | fingers | ) |
Dumps the current finger agnles onto the screen.
| fingers | Unit in degrees 0 to 6800 |
| void kinova::KinovaComm::homeArm | ( | void | ) |
This function move the arm to the "home" position. The code replicates the function of the "home" button on the user controller by "pressing" the home button long enough for the arm to return to the home position.
| bool kinova::KinovaComm::isHomed | ( | void | ) |
Determines whether the arm has returned to its "Home" state. Checks the current joint angles, then compares them to the known "Home" joint angles.
| void kinova::KinovaComm::initFingers | ( | void | ) |
This function initializes the fingers of the robotical arm. After the initialization, the robotical arm is in angular control mode. If you want to use the cartesian control mode, use the function setCartesianControl(). Move fingers to the full-open position to initialize them for use.
| void kinova::KinovaComm::setEndEffectorOffset | ( | unsigned int | status, |
| float | x, | ||
| float | y, | ||
| float | z | ||
| ) |
This function Set the end effector offset's parameters. The end effector's offset is a translation offset applied to the end effector of the robotic arm.
| status | indicates if the offset is applied or not (0 = not applied, 1 = applied) |
| x | Unit in meter |
| y | Unit in meter |
| z | Unit in meter |
| void kinova::KinovaComm::getEndEffectorOffset | ( | unsigned int & | status, |
| float & | x, | ||
| float & | y, | ||
| float & | z | ||
| ) |
This function get the end effector offset's parameters. The end effector's offset is a translation offset applied to the end effector of the robotic arm.
| status | indicates if the offset is applied or not (0 = not applied, 1 = applied) |
| x | Unit in meter |
| y | Unit in meter |
| z | Unit in meter |


Introduction
HTML (Hypertext Markup Language) is the most basic building block of the Web. It defines the meaning and structure of web content. Other technologies besides HTML are generally used to describe a web page's appearance/presentation (CSS) or functionality/behavior (JavaScript).
"Hypertext" refers to links that connect web pages to one another, either within a single website or between websites. Links are a fundamental aspect of the Web. By uploading content to the Internet and linking it to pages created by other people, you become an active participant in the World Wide Web.
HTML uses "markup" to annotate text, images, and other content for display in a Web browser. HTML markup includes special "elements" such as <head>
, <title>
, <body>
, <header>
, <footer>
, and many others.
An HTML element is set off from other text in a document by "tags", which consist of the element name surrounded by "<" and ">". The name of an element inside a tag is case insensitive. That is, it can be written in uppercase, lowercase, or a mixture. For example, the <title>
tag can be written as <Title>
, <TITLE>
, or in any other way.
Page Structure
Webpages can and will look pretty different from one another, but they all tend to share similar standard components, unless the page is displaying a fullscreen video or game, is part of some kind of art project, or is just badly structured:
Header
Usually a big strip across the top with a big heading and/or logo. This is where the main common information about a website usually stays from one webpage to another.
Navigation Bar
Links to the site's main sections; usually represented by menu buttons, links, or tabs. Like the header, this content usually remains consistent from one webpage to another — having an inconsistent navigation on your website will just lead to confused, frustrated users. Many web designers consider the navigation bar to be part of the header rather than a individual component, but that's not a requirement; in fact some also argue that having the two separate is better for accessibility, as screen readers can read the two features better if they are separate.
Main Content
A big area in the center that contains most of the unique content of a given webpage, for example the video you want to watch, or the main story you're reading, or the map you want to view, or the news headlines, etc. This is the one part of the website that definitely will vary from page to page!
Sidebar
Some peripheral info, links, quotes, ads, etc. Usually this is contextual to what is contained in the main content (for example on a news article page, the sidebar might contain the author's bio, or links to related articles) but there are also cases where you'll find some recurring elements like a secondary navigation system.
Footer
A strip across the bottom of the page that generally contains fine print, copyright notices, or contact info. It's a place to put common information (like the header) but usually that information is not critical or secondary to the website itself. The footer is also sometimes used for SEO purposes, by providing links for quick access to popular content.
Accessibility
Accessibility is the practice of making your websites usable by as many people as possible — we traditionally think of this as being about people with disabilities, but really it also benefits other groups such as those using mobile devices, or those with slow network connections.
You could also think of accessibility as treating everyone the same, and giving them the same opportunities, no matter what their ability or circumstances. In the same way that it is not right to exclude someone from a physical building because they are in a wheelchair (public buildings generally have wheelchair ramps or elevators these days), it is also not right to exclude someone from a website because they have a visual impairment. We are all different, but we are all human, and therefore have the same (human) rights.
Accessibility is the right thing to do, but it is also part of the law in some countries, and it can open up some significant markets that otherwise wouldn't be able to use your services, buy your products, etc.
Accessibility and the best practices it entails can benefit everyone:
- Semantic HTML (which improves accessibility) also improves SEO, making your site more findable/marketable.
- Caring about accessibility demonstrates good ethics/morals, which improves your public image.
- Other good practices that improve accessibility also make your site more usable by other groups, such as mobile phone users, those on a low network speed, etc. In fact, everyone can benefit from many such improvements.
- Did we mention it is also the law in some places?
CSS
CSS (Cascading Style Sheets) allows you to create great looking web pages, but how does it work under the hood? This article explains what CSS is, how the browser turns HTML into a Document Object Model (DOM), how CSS is applied to parts of the DOM, some very basic syntax examples, and what code is used to actually include our CSS in our web page.
Web browsers apply CSS rules to a document to affect how they are displayed. A CSS rule is formed from:
- A set of properties, which have values set to update how the HTML content is displayed, for example, I want my element's width to be 50% of its parent element, and its background to be red.
- A selector, which selects the element(s) you want to apply the updated property values to. For example, I want to apply my CSS rule to all the paragraphs in my HTML document.
How the Web Works
When you type a web address into your browser (for our analogy that's like walking to the shop):
- The browser goes to the DNS server, and finds the real address of the server that the website lives on (you find the address of the shop).
- The browser sends an HTTP request message to the server, asking it to send a copy of the website to the client (you go to the shop and order your goods). This message, and all other data sent between the client and the server, is sent across your internet connection using TCP/IP.
- If the server approves the client's request, the server sends the client a "200 OK" message, which means "Of course you can look at that website!
- The browser assembles the small chunks into a complete website and displays it to you (the goods arrive at your door — new shiny stuff, awesome!).


Register
Open Source Summit
Name
Email Address
Github Username (optional)
Email id used for Kshitij registration (optional)
College
{% for college in colleges %}
{% endfor %}
×


Home
Portfolio
Standard
Sample 2
Sample 3
About
Blog
Blog 1
Blog 2
Blog 3
Contact
Standard
Sample 2
Sample 3
Sample 4
Sample 5
Sample Form 3
This is a Sample Form
Banana
Apple
Male
Female
Favorite Genre
Rock n Roll
Bio
File
Submit
Phone
URL
Color
Home
Back to Contact Menu


Seer Reva:
These are remains of the dead, trampled by a despot... I can feel their bitterness, even after one thousand years!
You have brought over 100 ash urns at once!  As I promised, I will grant you a special prize! Take it!
Continue the mission.
Quit the mission.


_Holy_Smoke_ (R) *** (out of ****)
Up until a couple of days ago, the latest film from idiosyncratic New Zealand-born director Jane Campion bore the more exclamatory moniker _Holy_Smoke!_--an interjection that will serve as many people's immediate reaction to the picture. It certainly was mine--in a good way. The basic plot synopsis doesn't clue one in to the twisted path this unique film takes. A young Australian named Ruth (Kate Winslet) returns home from a trip to India a changed woman, having fallen under the spell of a spiritual guru. Deeply concerned, her family enlists the services of American P.J. Waters (Harvey Keitel), a cult deprogrammer with an impeccable success record. P.J.'s track record doesn't stand a chance, however, when Ruth turns out to be as headstrong as he is.
Thus the stage is set for a traditional role reversal; as Ruth's devotion to her guru fades away, P.J. finds himself falling under the influence of a different cult--Ruth's formidable sexual allure--and he is helpless to resist. But this being a Campion film, the story hardly unfolds in a traditional manner. Walking into the auditorium, one would not expect to see Keitel wearing a dress and full makeup for the last 20 or so minutes. Then there are the surreal visual touches to rival the talking lima beans in Campion's _The_Portrait_of_a_Lady_, such as the comical parade of Ruth's past lovers, all of whom have twinkling eyes and teeth. It goes without saying that these flights of fancy lends the film a bizarre fascination.
Which, I believe, is the point. _Holy_Smoke_ is all about the strange spells one inexplicably gets cast under, so it's only fitting that the film itself craft one of its own. But the audacity of Campion (and her writing partner and sister, Anna) ultimately plays a smaller role in the film's success than a more concrete quality: the performances. It's a testament to Keitel's work that P.J.'s emotional descent remains believable while in drag. More impressive, though, is Winslet, who once again gets to bare another aspect of her being (in every sense) as Ruth. It's refreshing to see Winslet follow _Titanic_'s phenomenal commercial success by returning to the edgy roles in smaller films that earned her recognition in the first place. As _Holy_Smoke_ displays, the work proves more admirable and rewarding than anything in a big mainstream Hollywood picture (such as _End_of_Days_, which she was offered and understandably declined).
Michael Dequina<EMAIL_ADDRESS>|<EMAIL_ADDRESS>|<EMAIL_ADDRESS>|<EMAIL_ADDRESS>Mr. Brown's Movie Site: http://welcome.to/mrbrown CinemaReview Magazine: http://www.CinemaReview.com on ICQ: #25289934 | on AOL Instant Messenger: MrBrown23
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


--- layout: post title: Glu Mobile launches Chu Chu Rocket! date: 2006-06-06 00:00:00 categories: mobile play ---
Glu Mobile launches Chu Chu Rocket!: "Available from all European operators beginning this month, Chu Chu Rocket! Challenges players to successfully guide space mice (ChuChus) through treacherous space ports infested with preying cats (KapuKapus), attempting to avoid capture and steer the mice towards the waiting escape rockets."
There go my train journeys...