semanticidentity.comsemanticidentity.comCopyright ODRL Initiative 2010-11. All Rights Reserved.
This document describes how to encode the ODRL Version 2.0 model and vocabulary using XML.
This is the third public Working Draft of the ODRL V2.0 XML Encoding Specification document produced by the ODRL Version 2.0 Working Group. The ODRL Initiative publishes a Working Draft for review by working group members and other interested parties. The ODRL Version 2.0 Working Group expects to advance this document to a Draft Specification once the Working Group is satisfied the encoding has broad consensus and demonstrated at least two interoperable implementations.
Comments on this document should be sent to editors and discussion of this document takes place on the public working group mailing list odrl-version2@odrl.net archived at http://odrl.net/pipermail/odrl-version2_odrl.net/.
This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than "work in progress". Publication as a Working Draft does not imply endorsement by the ODRL Initiative.
The ODRL Version 2.0 language is defined by the ODRL Model [ODRL-MODEL] and ODRL Common Vocabulary [ODRL-VOCAB] in an abstract manner to capture the semantics of the expression, without any specific syntax and/or encoding method.
This document describes how to encode both the Model and Common Vocabulary, including any community developed Profiles, using the XML syntax [XML] with XML Schema [XML-SCHEMA] and XML Schema Datatypes [XML-SCHEMA-DT]
This document utlilises the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in accordance to [RFC2119]. Lowercase wording is used in this document.
The XML Namespace [XML-NAME] for the ODRL Version 2.0 Core Model:
http://odrl.net/2.0/
This Namespace URI must be used to uniquely identify ODRL Version 2.0 semantics.
Examples in this document will use "o" as the prefix for this Namespace. However, any prefix may be utilised as long as it is associated with the correct Namespace.
The ODRL Common Vocabulary terms must be encoded using URIs. A single URI will represent each of the terms in the Common Vocabulary created by appending the term identifier with the XML Namespace. This URI shall then be used as the values in the ODRL XML expressions for Actions, Constraints, Roles etc. For example, the Play action would be represented as:
http://odrl.net/2.0/play
To enable compact URIs, this encoding also supports the use of Qualified Names (QNames) [XML-NAME] for the specification of the value identifiers. For example, the previous URI may also be represented as:
o:play
In addition, Qualified Codes [Q-CODE] may also be used for vocabulary values. QCodes are similar to QNames but also allow numeric values as the first characters of the value.
As much as possible, each of the core entities (UML Classes) from the ODRL Model will be represented by an XML element of the same name. Additionally, each entity attribute will be represented as an XML attribute of the parent element. The fixed values defined in the Model are represented as enumerated types. Cardinalities are also represented with XML Schema occurrence rules.
The Policy element may contain the following attributes:
The Policy element may contain the following elements:
The Asset and Relation association class are merged into a single Asset element and may contain the following attributes:
The Party and Role association class entities are merged into a single Party element and may contain the following attributes:
The Permission element may contain the following elements:
The Prohibition element may contain the following elements:
The Duty element may contain the following elements:
The Duty element may contain the following attributes:
The Action element may contain the following attribute:
The Constraint element may contain the following attributes:
In some cases where Duties refer to (external) Assets, it will be necessary to package the ODRL XML expression with the representation of that (external) Asset. This XML Encoding specification does not mandate any specific packaging mechanism as communities will utilise their preferred options for data interoperability.
The examples in Section 5 give concrete instances of these XML encoding rules for the Model and Common Vocabulary. Appendix A shows the formal XML Schema that encapsulates these rules.
In some scenarios, the Asset of an ODRL Policy maybe also be XML or HTML markup. In these cases specific cases, it makes sense to enable the ODRL Policy to be articulated as part of the Asset and to support abbreviated expressions. All default values should be assumed. The typical scenario would require either a Permission or a Prohibition element to be linked to the XML/HTML markup. The preferred method of linking is to utilise the XML ID attribute. The source Asset markup should be identified with an ID attribute and the ODRL Asset element can then refer to this ID as the UID (as a URI hash fragment). An example is shown below.
<rnews:Article xml:id="item8HEX">
<rnews:title>Allies are Split<rnews:title>
<rnews:description>Rebel fighters take control...<rnews:description>
...
<o:permission>
<o:asset uid="#item8HEX"/>
<o:action name="o:distribute"/>
<o:constraint name="o:dateTime" operator="o:gteq" rightOperand="2011-11-11"/>
</o:prohibition>
</rnews:Article>
These examples represent the XML Encodings for all the Scenarios described in the [ODRL-Model] document.
<o:policy xmlns:o="2.0" type="o:set" uid="http://example.com/policy:0099">
<o:permission>
<o:asset uid="http://example.com/asset:9898" relation="o:target"/>
<o:action name="o:publish"/>
</o:permission>
<o:prohibition>
<o:asset uid="http://example.com/asset:9898" relation="o:target"/>
<o:action name="o:modify"/>
</o:prohibition>
</o:policy>
<o:policy xmlns:o="2.0" type="o:offer" uid="http://example.com/policy:0231">
<o:permission>
<o:asset uid="http://example.com/music:4545" relation="o:target"/>
<o:action name="o:play"/>
<o:party uid="http://example.com/sony:10" function="o:assigner"/>
<o:duty uid="d1">
<o:action name="o:pay"/>
<o:asset uid="http://example.com/ubl:AUD0.50"/>
</o:duty>
</o:permission>
<o:permission>
<o:asset uid="http://example.com/music:4545" relation="o:target"/>
<o:action name="o:copy"/>
<o:constraint name="o:numberOfUses" operator="o:lteq" rightOperand="1"/>
<o:party uid="http://example.com/sony:10" function="o:assigner"/>
<o:duty uid="#d1"/>
</o:permission>
</o:policy>
<!-- External Asset -->
<ubl:PriceAmount xml:id="http://example.com/ubl:AUD0.50"
xmlns:ubl="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
currencyID="AUD">0.50</ubl:PriceAmount>
<!-- External Asset -->
<o:policy xmlns:o="2.0" type="o:agreement" uid="http://example.com/policy:9001">
<o:permission>
<o:asset uid="http://example.com/music:4545" relation="o:target"/>
<o:action name="o:play"/>
<o:party uid="http://example.com/sony:10" function="o:assigner"/>
<o:party uid="http://example.com/billie:888" function="o:assignee"/>
<o:duty uid="d1">
<o:action name="o:pay"/>
<o:asset uid="http://example.com/ubl:AUD0.50"/>
</o:duty>
</o:permission>
<o:permission>
<o:asset uid="http://example.com/music:4545" relation="o:target"/>
<o:action name="o:copy"/>
<o:constraint name="o:numberOfUses" operator="o:lteq" rightOperand="1"/>
<o:party uid="http://example.com/sony:10" function="o:assigner"/>
<o:party uid="http://example.com/billie:888" function="o:assignee"/>
<o:duty uid="#d1"/>
</o:permission>
</o:policy>
<!-- External Asset -->
<ubl:PriceAmount xml:id="http://example.com/ubl:AUD0.50"
xmlns:ubl="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
currencyID="AUD">0.50</ubl:PriceAmount>
<!-- External Asset -->
<o:policy xmlns:o="2.0" type="o:request" uid="http://example.com/policy:04311">
<o:permission>
<o:asset uid="http://example.com/news:0099" relation="o:target"/>
<o:action name="o:display"/>
<o:party uid="http://example.com/guest:0589" function="o:assignee"/>
</o:permission>
</o:policy>
<o:policy xmlns:o="2.0" type="o:ticket" uid="http://example.com/policy:04311">
<o:permission>
<o:asset uid="http://example.com/game:4589" relation="o:target"/>
<o:action name="o:play"/>
<o:constraint name="o:currentDate" operator="o:lteq" rightOperand="2010-12-31"/>
</o:permission>
</o:policy>
<o:policy xmlns:o="2.0" xmlns:iso3116="http://www.itu.int/tML/tML-ISO-3166"
type="o:offer" uid="http://example.com/policy:5531">
<o:permission>
<o:asset uid="http://example.com/wallpaper:2321" relation="o:target"/>
<o:action name="o:distribute"/>
<o:constraint name="o:spatial" operator="o:eq" rightOperand="iso3016:it"/>
<o:party uid="http://example.com/sony:99" function="o:assigner"/>
<o:duty uid="d1">
<o:action name="o:pay"/>
<o:asset uid="http://example.com/ubl:EU1000.00" relation="o:target"/>
</o:duty>
<o:duty uid="d2">
<o:action name="o:nextPolicy"/>
<o:asset uid="http://example.com/policy:7777" relation="o:target"/>
</o:duty>
</o:permission>
</o:policy>
<o:policy xmlns:o="2.0" type="o:set" uid="http://example.com/policy:7777">
<o:permission>
<o:asset uid="http://example.com/wallpaper:2321" relation="o:target"/>
<o:action name="o:display"/>
</o:permission>
</o:policy>
<!-- External Asset -->
<ubl:PriceAmount xml:id="http://example.com/ubl:EU1000.00"
xmlns:ubl="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
currencyID="EUR">1000.00</ubl:PriceAmount>
<!-- External Asset -->
<o:policy xmlns:o="2.0" xmlns:p3p="http://www.w3.org/2002/01/P3Pv1"
type="o:privacy" uid="http://example.com/policy:1111">
<o:permission>
<o:asset uid="http://example.com/billie:888:personal-data" relation="o:target"/>
<o:action name="o:distribute"/>
<o:constraint name="o:purpose" operator="o:eq" rightOperand="p3p:contact"/>
<o:party uid="http://example.com/billie:888" function="o:assigner"/>
<o:party uid="http://example.com/gov:health:au" function="o:assignee"/>
<o:duty>
<o:action name="o:delete"/>
<o:asset uid="http://example.com/billie:888:personal-data" relation="o:target"/>
<o:constraint name="o:dateTime" operator="o:eq" rightOperand="P30D"/>
</o:duty>
</o:permission>
</o:policy>
<o:policy xmlns:o="2.0" type="o:agreement" uid="http://example.com/policy:3433" conflict="perm">
<o:permission>
<o:asset uid="http://example.com/music:1234908" relation="o:target"/>
<o:action name="o:play"/>
<o:party uid="http://example.com/sony:10" function="o:assigner"/>
<o:party uid="http://example.com/billie:888" function="o:assignee"/>
</o:permission>
<o:prohibition>
<o:asset uid="http://example.com/music:1234908" relation="o:target"/>
<o:action name="mobile:ringtone"/>
<o:party uid="http://example.com/sony:10" function="o:assigner"/>
<o:party uid="http://example.com/billie:888" function="o:assignee"/>
</o:prohibition>
</o:policy>
<o:policy xmlns:o="2.0" type="o:agreement" uid="http://example.com/policy:5531" inheritAllowed="true">
<o:permission>
<o:asset uid="http://example.com/report:2321" relation="o:target"/>
<o:action name="o:print"/>
<o:party uid="http://example.com/pub:88" function="o:assigner"/>
<o:party uid="http://example.com/billie:888" function="o:assignee"/>
</o:permission>
</o:policy>
<o:policy xmlns:o="2.0" type="o:type:agreement" uid="http://example.com/policy:9999"
inheritFrom="http://example.com/policy:5531">
<o:permission>
<o:asset uid="http://example.com/report:2333" relation="o:target"/>
<o:action name="o:display"/>
<o:party uid="http://example.com/pub:88" function="o:assigner"/>
<o:party uid="http://example.com/class:IT01" function="o:assignee" scope="o:group"/>
</o:permission>
</o:policy>
<o:policy xmlns:o="2.0" type="o:agreement" uid="http://example.com/policy:5109">
<o:permission>
<o:asset uid="http://example.com/myPlace:billie:photos:football2010" relation="o:target"/>
<o:action name="o:display"/>
<o:party uid="http://example.com/myPlace:billie" function="o:assigner"/>
<o:party uid="http://example.com/myPlace:network:football" function="o:assignee" scope="o:group"/>
</o:permission>
</o:policy>
<o:policy xmlns:o="2.0" type="o:set" uid="http://example.com/policy:881212">
<o:permission>
<o:asset uid="http://example.com/archive2010" relation="o:target"/>
<o:asset uid="http://example.com/x/dataase" relation="x:collection"/>
<o:action name="o:index"/>
</o:permission>
</o:policy>
The W3C Privacy Rulesets Editor's Draft has been developed by the W3C Device APIs and Policy Working Group as a scheme for defining privacy rulesets: bundles of user privacy preferences that can be conveyed together with user data in the context of a web site or application interaction. The document defines three Privacy Elements with a number of attributes, summarised here:
The following example shows how to represent the Privacy Ruleset "Internal customization/personalization" from the document.
<o:policy xmlns:o="2.0" xmlns:dap="http://www.w3.org/2009/dap/" type="o:privacy"
uid="http://example.com/policy:2442">
<o:permission>
<o:asset uid="http://example.comjane-doe:personal-data" relation="o:target"/>
<o:action name="o:sharing"/>
<o:constraint name="o:purpose" operator="o:eq" rightOperand="dap:internal"/>
<o:duty uid="d1">
<o:action name="o:delete"/>
<o:constraint name="o:dateTime" operator="o:eq" rightOperand="P35D"/>
</o:duty>
</o:permission>
<o:permission>
<o:asset uid="http://example.com/jane-doe:personal-data" relation="o:target"/>
<o:action name="o:secondaryUse"/>
<o:constraint name="o:purpose" operator="o:eq" rightOperand="dap:customization"/>
<o:duty uid="#d1"/>
</o:permission>
</o:policy>
The Open Data Commons provides a number of licenses for the sharing of open databases. One example is the Open Database License (ODbL) v1.0 which enables you to "share, create, and adapt" the database as long as you "attribute, share-a-like, and keep open" the outcomes.
The following example shows how to represent that license in ODRL. Note that the "keep open" option is represented as a distribute Prohibition with "drm-restriction" constraint. Also, since Open Data Commons are "instant" licenses, no assignee is indicated, but assumed to be the recipient of the database asset.
<o:policy xmlns:o="2.0" xmlns:odc="http://www.opendatacommons.org/"
type="o:agreement" uid="http://example.com/policy:0101Z">
<o:permission>
<o:asset uid="http://example.com/gov.au:database:environment" relation="o:target"/>
<o:action name="o:share"/>
<o:party uid="http://example.com/gov.au:env-dept" function="o:assigner"/>
<o:duty uid="d1">
<o:action name="o:attribute"/>
</o:duty>
<o:duty uid="d2">
<o:action name="o:attachPolicy"/>
</o:duty>
<o:duty uid="d3">
<o:action name="o:shareAlike"/>
</o:duty>
</o:permission>
<o:permission>
<o:asset uid="http://example.com/database:environment" relation="o:target"/>
<o:action name="o:derive"/>
<o:party uid="http://example.com/gov.au:env-dept" function="o:assigner"/>
<o:duty uid="#d1"/>
<o:duty uid="#d2"/>
<o:duty uid="#d3"/>
</o:permission>
<o:permission>
<o:asset uid="http://example.com/database:environment" relation="o:target"/>
<o:action name="o:transform"/>
<o:party uid="http://example.com/gov.au:env-dept" function="o:assigner"/>
<o:duty uid="#d1"/>
<o:duty uid="#d2"/>
<o:duty uid="#d3"/>
</o:permission>
<o:prohibition>
<o:asset uid="http://example.com/database:environment" relation="o:target"/>
<o:action name="o:distribute"/>
<o:constraint name="o:system" operator="o:eq" rightOperand="odc:drm-restriction"/>
<o:party uid="http://example.com/gov.au:env-dept" function="o:assigner"/>
</o:prohibition>
</o:policy>
The Extensible Messaging and Presence Protocol [XMPP-CORE] provides a real-time transport mechanism for structured XML information which may be useful for transporting ODRL information over XMPP. ODRL XML expressions may be sent via the XML message stanza defined in XMPP Core using either of the following:
The message stanza should not have a 'type' attribute, but may have any defined type that is appropriate to the communications context. The policy element should be the only child element of the message stanza. The 'id' attribute of the message stanza may be set to the value of the ODRL Policy uid.
The following example shows "Scenario 4.4 Request" sent as a direct message from the requester to the asset owner.
<message from="william@shakespeare.biz"
to="hamlet@denmark.lit"
id="uuid:3932ASDC4192SUAS3281">
<o:policy xmlns:o="2.0" type="o:request" uid="http://example.com/policy:04311">
<o:permission>
<o:asset uid="http://example.com/news:0099" relation="o:target"/>
<o:action name="o:display"/>
<o:party uid="http://example.com/guest:0589" function="o:assignee"/>
</o:permission>
</o:policy>
</message>
The XMPP publish-subscribe protocol provides a way to send information to a number of subscribers.
The following example shows "Scenario 4.54 Ticket" published to a pubsub node sent to all subscribers.
<iq type="set"
from="hamlet@denmark.lit"
to="pubsub.jabber.org"
id="someID">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<publish node="ODRL-TICKETS">
<item id="uuid:2341SEFS9827WGAS1234">
<o:policy xmlns:o="2.0" type="o:ticket" uid="http://example.com/policy:04311">
<o:permission>
<o:asset uid="http://example.com/game:4589" relation="o:target"/>
<o:action name="o:play"/>
<o:constraint name="o:dateTime" operator="o:lteq" rightOperand="2010-12-31"/>
</o:permission>
</o:policy>
</item>
</publish>
</pubsub>
</iq>
XMPP is used by a number of distributed Social Networks, such as OneSocialWeb. In such cases, the use of an "access-control" language can be addressed with ODRL policy expressions for the fine-grained permissions to profile, activity, and social relationship data.
The example below shows a user's Birthday attribute (from vCard) allowed to be viewed for friends only (taken from the vCard over XMPP draft document). (See Section 4 on referring to inline Assets.)
<birthday xml:id="bd"> <datetime>1850-04-06T21:23:00-07:00</datetime> <place>Stratford-upon-Avon</place> ... </birthday> <o:permission> <o:asset uid="#bd"/> <o:action name="o:display"/> <o:party uid="hamlet@denmark.lit" function="o:assignee" scope="o:allConnections" /> </o:permission>
The example below shows a Status Update for everyone to view (taken from the Activity Stream over XMPP draft document).
<entry>
<activity:object xml:id="ao100">
<activity:object-type>http://onesocialweb.org/spec/1.0/object/status</activity:object-type>
<content type="text/plain">to be or not to be ?</content>
</activity:object>
<o:permission>
<o:asset uid="#ao100"/>
<o:action name="o:display"/>
<o:party uid="hamlet@denmark.lit" function="o:assignee" scope="o:all" />
</o:permission>
</entry>
The XML Schema file will be located at:
http://odrl.net/2.0/schema.xsd
The XML Schema for ODRL Version 2.0 is shown below.
<xs:schema xmlns:o="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="2.0" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="policy">
<xs:complexType>
<xs:complexContent>
<xs:extension base="o:assetCT">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="permission" type="o:permCT" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="prohibition" type="o:prohibCT" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="type" type="o:URIQnameQcode" use="required"/>
<xs:attribute name="conflict" type="o:conflictVOC"/>
<xs:attribute name="undefined" type="o:undefinedVOC"/>
<xs:attribute name="inheritAllowed" type="xs:boolean"/>
<xs:attribute name="inheritFrom" type="xs:anyURI"/>
<xs:attribute name="inheritRelation" type="o:URIQnameQcode"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:complexType name="assetCT" abstract="true">
<xs:attribute name="uid" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="assetRelationCT">
<xs:complexContent>
<xs:extension base="o:assetCT">
<xs:attribute name="relation" type="o:URIQnameQcode" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="partyCT" abstract="true">
<xs:attribute name="uid" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="partyRoleCT">
<xs:complexContent>
<xs:extension base="o:partyCT">
<xs:attribute name="function" type="o:URIQnameQcode" use="required"/>
<xs:attribute name="scope" type="o:URIQnameQcode"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="prohibCT">
<xs:sequence>
<xs:element name="asset" type="o:assetRelationCT" maxOccurs="unbounded"/>
<xs:element name="action" type="o:actionCT"/>
<xs:element name="constraint" type="o:constraintCT" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="party" type="o:partyRoleCT" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="permCT">
<xs:complexContent>
<xs:extension base="o:prohibCT">
<xs:sequence>
<xs:element name="duty" type="o:dutyCT" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="actionCT">
<xs:attribute name="name" type="o:URIQnameQcode" use="required"/>
</xs:complexType>
<xs:complexType name="constraintCT">
<xs:attribute name="name" type="o:URIQnameQcode" use="required"/>
<xs:attribute name="operator" type="o:URIQnameQcode" use="required"/>
<xs:attribute name="rightOperand" type="o:listOfValues" use="required"/>
<xs:attribute name="status" type="xs:string"/>
</xs:complexType>
<xs:complexType name="dutyCT">
<xs:sequence>
<xs:element name="action" type="o:actionCT" minOccurs="0"/>
<xs:element name="asset" type="o:assetRelationCT" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="constraint" type="o:constraintCT" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="party" type="o:partyRoleCT" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="uid" type="xs:anyURI"/>
</xs:complexType>
<xs:simpleType name="listOfValues">
<xs:list itemType="xs:string"/>
</xs:simpleType>
<xs:simpleType name="conflictVOC">
<xs:restriction base="xs:string">
<xs:enumeration value="perm"/>
<xs:enumeration value="prohibit"/>
<xs:enumeration value="invalid"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="undefinedVOC">
<xs:restriction base="xs:string">
<xs:enumeration value="support"/>
<xs:enumeration value="ignore"/>
<xs:enumeration value="invalid"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="URIQnameQcode">
<xs:union memberTypes="xs:anyURI xs:QName o:QCode" />
</xs:simpleType>
<xs:simpleType name="QCode">
<xs:restriction base="xs:token">
<xs:pattern value="[^\s:]+:[^\s]+"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
The editors gratefully acknowledge feedback and contributions to this document from:
| [ODRL-MODEL] | R. Iannella & H. Hundacker & D. Paehler & A. Kasten & S. Guth (eds). Open Digital Rights Language (ODRL) Version 2.0 - Core Model.
Draft Specification, ODRL Initiative, 15 October 2010. http://odrl.net/2.0/DS-ODRL-Model.html |
| [ODRL-VOCAB] | S. Guth & R. Iannella (eds). Open Digital Rights Language (ODRL) Version 2.0 - Common Vocabulary.
Working Draft, ODRL Initiative, 19 October 2010. http://odrl.net/2.0/WD-ODRL-Vocab.html |
| [Q-CODE] | NewsML Specification Version 2.4. International Press Telecommunications Council (IPTC) 2009 http://www.iptc.org/std/NewsML-G2/2.4/specification/NewsML-G2_2.4-spec-PCL.pdf |
| [RFC2119] | Key words for use in RFCs to Indicate Requirement Levels, S. Bradner.
The Internet Society, March 1997. http://www.ietf.org/rfc/rfc2119.txt |
| [XML] | T. Bray & J. Paoli & C. M. Sperberg-McQueen & E. Maler & F. Yergeau (eds). Extensible Markup Language (XML) 1.0 (Fifth Edition).
W3C Recommendation 26 November 2008. http://www.w3.org/TR/xml/ |
| [XML-SCHEMA] | H. S. Thompson & D. Beech & M. Maloney & N. Mendelsohn (eds). XML Schema Part 1: Structures Second Edition.
W3C Recommendation 28 October 2004. http://www.w3.org/TR/xmlschema-1/ |
| [XML-SCHEMA-DT] | P. V. Biron & K. Permanente & A. Malhotra (eds). XML Schema Part 2: Datatypes Second Edition.
W3C Recommendation 28 October 2004. http://www.w3.org/TR/xmlschema-2/ |
| [XML-NAME] | T. Bray & D. Hollander & A. Layman & R. Tobin & H. S. Thompson (eds). Namespaces in XML 1.0 (Third Edition).
W3C Recommendation 8 December 2009. http://www.w3.org/TR/xml-names/ |
| [XMPP-CORE] | P. Saint-Andre (ed). Extensible Messaging and Presence Protocol (XMPP): Core.
IETF RFC3920 October 2004. http://tools.ietf.org/html/rfc3920 |