2.0 Common Vocabulary – Constraint Draft Changes

Proposed Update to Common Vocabulary that includes changes to Constraint model and Payment action
For detailed changes from Final Specification, see the HTML Differences Report

—-UPDATES to APPLY

Update to use the new URI http://www.w3.org/ns/odrl/2/
All identifiers names must now match the ODRL Ontology identifiers

—-UPDATES to APPLY

Draft Specification: 04 April 2014

Location: http://www.w3.org/community/odrl/two/vocab/

(when final)

Editors:
Renato Iannella, Semantic Identity, riATsemanticidentity.com
Michael Steidl, IPTC, mdirectorATiptc.org
Susanne Guth, Vodafone, susanne.guthATvodafone.com

Status of this document

This specification was published by the W3C ODRL Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

The W3C ODRL Community Group publishes a Final Specification to indicate that the document is believed to be mature and stable for implementation by the wider community. This Final Specification is now endorsed by the W3C ODRL Community Group as appropriate for widespread deployment and that promotes the Community Groups’s mission.

Discussion and feedback of this document takes place on the W3C ODRL Community Group mailing list (see Contributor Archive). Feedback from the public is encouraged and can be send to public-odrl@w3.org (see Public Archive).


Copyright © 2012 the Contributors to the Final Specification, published by the W3C ODRL Community Group under the W3C Community Final Specification Agreement (FSA). A human-readable summary is available.

Table of contents


1. Overview

The ODRL policy language has benefited from a robust underlying information model that has captured its semantics and provided extensibility paths for various communities. The Common Vocabulary specifies the terms (vocabulary) used by the Core Model [ODRL-MODEL] for policy expression needs.

The Common Vocabulary includes additional semantics and meets requirements gathered from the wider community, the latest research on access control, obligation management, privacy, social networks, publishers, as well as the past experiences in implementations and research of ODRL. The complete requirements for the Version 2.0 Model are documented [ODRL-REQ].

This specification utilises the key words “MUST”, “MAY”, “REQUIRED”, and “OPTIONAL” in accordance to [RFC-2119]. These words are used in lowercase in this document.

2. ODRL Common Vocabulary

The Common Vocabulary offers a wide range of vocabulary terms for the expression of Types, Permissions, Prohibitions, Constraints, and Duties over assets. Additional and/or different semantics may be defined in ODRL Profiles (see also Section 3 Profiles ) for particular ODRL application areas defined by industry and community sectors.

All terms of the Common Vocabulary are related to specific entities of the Core Model [ODRL-MODEL]:

  • Types for Polices
  • Actions for Permissions, Prohibitions, and Duties
  • Names and Operators for Constraints
  • Functions and Scope for Roles played by Parties
  • Relations for Assets

The Namespace URI for the ODRL Version 2.0 Common Vocabulary is defined as:


http://w3.org/ns/odrl/2/

This Namespace URI must be used in all encodings of ODRL policies to refer to the ODRL Common Vocabulary terms. The Namespace URI uniquely identifies the ODRL Common Vocabulary term by appending the identifier of that term. In some cases the vocabulary term may have two (or more) identifiers in which case they are considered semantically equivalent (ie synonyms).

For example, below are the target and play terms:


http://w3.org/ns/odrl/2/target


http://w3.org/ns/odrl/2/play

2.1 Policy Types

Vocabulary terms in this section may be used as the “type” of the Policy Entity.

Table 1: Terms for the entity Type of the Policy Entity
Identifier Semantics Comment
agreement Policy expressions that are formal contracts (or licenses) stipulating all the terms of usage and all the parties involved. Must contain at least the Party entity with Assigner role and a Party with Assignee role. The latter being granted the terms of the Agreement from the former.
offer Policy expressions that propose terms of usage from an Asset owner Must contain a Party entity with Assigner role. The Offer may contain a Party entity with Assignee role, but does not grant any privileges to that Party.
privacy Policy expressions that stipulate the terms of usage over personal information. Must contain at least the Party entity with Assigner role and a Party with Assignee role. Must also contain a Duty on the assignee related to obligations towards managing the assigner’s Asset containing personal information. The Assignee is being granted the terms of the Privacy policy from the Assigner.
request Policy expressions that propose terms of usage to an Asset owner Must contain a Party entity with Assignee role. The Request may also contain the Party entity with Assigner role if this is known. No privileges are granted to any Party.
set Policy expressions that consists of entities from the complete model The Set is aimed at scenarios where there is an open criteria for the semantics of the policy expressions and typically refined by other systems/profiles that process the information at a later time. No privileges are granted to any Party.
ticket Policy expressions that stipulate the terms of usage and is redeemable by any Party who currently holds the Ticket in their possession May contain the Party entity with Assigner role and the Party entity with Assignee role. A Ticket (or Voucher) may be anonymous or personalised, where the holder of that Ticket may remain unknown or has to be identified. The holder, or if known, the Assignee, is being granted the terms of the Ticket from the Assigner (in known).

2.2 Actions

Vocabulary terms in this section may be used as the “name” of the Action entity for Permissions, Prohibitions , and Duties.

Table 2: Terms for the entity Action
Identifier
+ BT Broader Term
+ Usage with:
PP = Permission/Prohibition
Duty = Duty
Semantics Comment
acceptTracking
Usage: Duty
The Assigner requires that the Assignee(s) executes the act of accepting that the use of the Asset may be tracked The collected information may be tracked by the assigner, or may link to a Party with role function “trackingParty”.
aggregate
BT: use
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of using the Asset or parts of it as part of a composite collection
annotate
BT: use
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of adding notations/commentaries to the Asset A new asset is created including the annotations. [???]
anonymize
BT: use
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of anonymising the Asset For example, to remove identifying particulars for statistical or other purposes.
appendTo
BT: writeTo
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of adding data to the end of the Asset For example, the ability to add record to a database (the asset)
archive
BT: use
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of persistently storing the Asset Constraints may be used for temporal conditions.
attribute
Usage: Duty
The Assigner requires that the Assignee(s) executes the act of attributing the Asset to a Party May link to an Asset with the attribution information. May link to a Party with role function “attributedParty”.
concurrentUse
BT: use
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of multiple concurrent use of the Asset
delete
Usage: Duty
The Assigner requires that the Assignee(s) executes the act of permanently removing all copies of the Asset
derive
BT: use
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of creating a new derivative Asset from the Asset
digitize
BT: use
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of digitizing the Asset from its analogue form
display
BT: present
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of rendering the visual media Asset to an audience For example; displaying an image on a screen.
distribute
BT: use
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of distributing the Asset to a public audience
ensureExclusivity
Usage: Duty
The Assigner requires that the Assignee(s) executes the act of requiring the Assigner to ensure the Permission on the Asset is unique to the Assignee A duty in which the Assigner is the same as the Assignee and is obliged to ensure the Permission granted is exclusive.
execute
BT: use
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of running the computer program Asset. For example; machine executable code or Java such as a game or application.
extract
BT: reproduce
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of extracting parts of the Asset and an unchanged insert into another Asset. For reuse along with, or within, another asset, or to stand alone.
give
BT: transfer
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of transferring the ownership of the Asset and all related rights to a third-party without exchange of value Ownership is transferred to the recipient. The original asset must be deleted by the owner.
include
Usage: Duty
The Assigner requires that the Assignee(s) executes the act of including other related assets to fulfill the full duty. For example; Bio picture must be included in the attribution. Use of the Asset relation attribute is required.
index
BT: use
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of indexing the Asset into a collection of assets For example: to include the asset in a search engine database.
inform
Usage: Duty
The Assigner requires that the Assignee(s) executes the act of informing a Party that an action has been performed on the Asset May link to a Party with role function “informedParty”.
install
BT: use
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of loading the computer program Asset onto storage device ready for operation
lease
BT: use
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act that the Assignee makes available the Asset to a third-party for a fixed period of time with exchange of value During this period, the asset is only available by the third-party. Temporal constraints may be used. Next Policy is recommended for the third-party.
lend
BT: use
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act that the Assignee makes available the Asset to a third-party for a fixed period of time without exchange of value During this period, the asset is only available by the third-party. Temporal constraints may be used. Next Policy is recommended for the third-party.
move
BT: use
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of moving the Asset from one location to another one After the asset has been moved, the original copy must be deleted.
nextPolicy
Usage: Duty
The Assigner requires that the Assignee(s) executes the act of applying a specific Policy to a third-party for their use of the Asset Used to indicate the policy terms for downstream use of the asset. If the asset is modified (eg translated) as an outcome of the original Policy, then the Next Policy applies to the derived asset.
obtainConsent
Usage: Duty
The Assigner requires that the Assignee(s) executes the act of requiring explicit consent from a Party to perform the action on the Asset Used as a Duty for the asset owners to decide on a case-by-case basis. May link to a Party with role function “consentingParty”.
pay
Usage: Duty
The Assigner requires that the Assignee(s) executes the act of paying a financial amount to a Party for use of the Asset The payAmount constraint may be used to indicate the amount of the payment. The Payer is the Assignee and the Payee is the Assigner of the policy or, if specified, a new Party with role function “payeeParty”.
play
BT: present
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of rendering an audio Asset to an audience.
present
BT: use
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of rending media to an audience.
preview
BT: display
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of providing a short preview of the Asset to an audience. For example; the first 5 minutes of a movie.
print
BT: present
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of rendering an Asset onto paper or hard copy form to an audience. For example; creating a permanent, fixed (static), and directly perceivable representation of the asset.
read
BT: use
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of obtaining data from the asset For example, the ability to read a record from a database (the asset)
reproduce
BT: use
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of making an exact reproduction of the Asse
reviewPolicy
Usage: Duty
The Assigner requires that the Assignee(s) executes by a person the act of performing a review of the terms associated with the Asset. Used when human intervention is required to review the policy. May link to an Asset which represents the full policy information.
secondaryUse
BT: use
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of using the Asset for a purpose other than the purpose it was intended for For example, for marketing or profiling purposes.
sell
BT: transfer
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of transferring the ownership of the Asset and all related rights to a third-party in exchange of value. A Next Policy is recommended for the third-party
sublicense
BT: use
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of granting a sublicense for using the Asset to a third-party This action enables the assignee to create policies for the use of the asset for third-parties. Use of Next Policy to express any downstream constraints is recommended.
textToSpeech
BT: present
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of reading out loud a text Asset by a technical system
transfer
Usage: PP
The Assigner transfers/does not transfer the ownership of the Asset and all related rights in perpetuity to the Assignee(s).
transform
BT: use
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of transforming the digital Asset into another digital format Typically used to convert the asset into a different format for consumption/transfer on a third-party system and may also include the conversion of the policy [???].
translate
BT: use
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of translating the natural language of an Asset into another natural language. A new asset is created by that action.
uninstall
BT: use
Usage: Duty
The Assigner requires that the Assignee(s) executes the act of unloading the computer program Asset from a storage device and disabling its readiness for operation The asset is not longer accessible.
use
Usage: PP
The Assigner grants/does not grant the right for using the Asset to the Assignee(s). More details may be defined in a related licensing contract or commercial laws. Refined types of license-bases actions can be expressed by the narrower actions.
watermark
Usage: Duty
The Assigner requires that the Assignee(s) executes the act of applying a watermark to the Asset A linked asset may indicate the watermark to apply.
writeTo
BT: use
Usage: PP
The Assigner permits/prohibits the Assignee(s) to execute the act of writing to the Asset For example, the ability to write a record to a database (the asset)

Action Hierarchy Overview

Permission/Prohibition actions

  • transfer
  • use
    • aggregate
    • annotate
    • anonymize
    • archive
    • concurrentUse
    • digitize
    • distribute
    • derive
    • execute
    • index
    • install
    • move
    • present
      • display
        • preview
      • play
      • print
    • read
    • reproduce
      • extract
    • secondaryUse
    • textToSpeech
    • translate
    • transform
    • writeTo
      • appendTo

Permission/Prohibition actions towards third-parties only

  • (use)
    • lease
    • lend
    • sublicense
  • (transfer)
    • give
    • sell

Duty actions

  • acceptTracking
  • attribute
  • delete
  • ensureExclusivity
  • include
  • inform
  • nextPolicy
  • obtainConsent
  • pay
  • reviewPolicy
  • uninstall
  • watermark

2.3 Constraints

The Constraint entity has three mandatory attributes: name, operator, rightOperand and three optional attributes: dataType, unit, status. For example, to express that a Print Permission is constraint by a maximum of 10 times, create a Constraint entity where:

name = count
operator = lteq
rightOperand = 10

For the attribute rightOperand the values should be represented by standard data types such as Integer, Real, String, URI, etc which may be expressed by the dataType attribute. The unit attribute may provide additional information about the rightOperand value, such as currency types. The status attribute represents the current value of the constraint value, such as 5 for the current value of print outputs (from the above example).

Vocabulary terms in the below table may be used as the attribute “name” of the Constraint Entity.

Table 3: Terms for the attribute “name” of the entity Constraint
Identifier Semantics Comment
absolutePosition A point defined with absolute coordinates For example, JPEG image must be positioned at 100×100 pixel location. This may be used to express [PLUS] semantics.
absoluteSize The absolute dimension that the Asset may be resized For example, JPEG image must be reproduced onto an area no larger than A0. This may be used to express [PLUS] semantics.
count The numeric count indicating the number of times the corresponding entity may be exercised Should be a positive integer.
dateTime The date (and optional time and timezone) representing a point in time or period Date and Time value must conform to [ISO-8601] as represented in [W3CXMLSCHEMA]. The use of Timezone information is strongly recommended.
fileFormat The file format applicable to the Asset For example, this may be used to express [PLUS] semantics; only JPEG image may be distributed.
industry The defined industry sector applicable to the asset usage For example, publishing, financial.
language The natural language applicable to the asset usage For example, this may be used to express [PLUS] semantics; JPEG image may only be reproduced with Spanish text. Must use [BCP-47] codes.
deliveryChannel The delivery channel used for storing or communicating the asset For example, the asset may be distributed only on mobile networks.
elapsedTime A period of time in which the policy action can be exercised. The start of the period is when the action is first exercised.
event Specification of a defined event applicable to the asset usage For example, asset may be used at the “FIFA World Cup” only. To express events related to undertaking Duties, a specific event value has been defined:

  • policyUsage – the time period whilst the policy is being exercised

This will enable constraints to be expressed such as “event lt o:policyUsage” indicating before the policy is exercised.

media The media type in which the asset may be used For example, electronic, print, advertising, marketing. This may be used to express [PLUS] semantics.
meteredTime The maximum period of metered usage time Value must conform to [ISO-8601] as represented in [W3CXMLSCHEMA]. For example “P30H” indicates a 30 hour period.
payAmount The value of the financial payment The dataType attribute may be used to indicate the type of the value (eg decimal) and the unit attribute to indicate the currency.
percentage The amount (as a percentage) of the action applicable to the asset A numeric value from 0 to 100. For example, extract a maximum of 50% of the asset
product The specified Product or Service name For example, this may be used to express [PLUS] semantics; images may only be reproduced in the XYZ Magazine.
purpose Specification of a defined purpose applicable to the asset usage For example, educational use. [P3P] Purpose values may also be used.
recipient The party that receives the result of the Action on the Asset The right operand must identify one or more specific parties or categories of party
relativePosition A point defined with reference to another position For example, this may be used to express [PLUS] semantics; JPEG image must be positioned at the Top of the Page.
relativeSize The relative dimension that the Asset may be resized For example, this may be used to express [PLUS] semantics; JPEG image resized to maximum of 200%.
resolution The resolution at which the asset may be used For example, may be printed at 1200dpi.
spatial A code representing a geospatial area The code value and code source must be represented. For example, the ISO-3166 Country Codes and the Getty Thesaurus of Geographic Names. A URI should be used to represent this value.
timeInterval Recurring period of time in which the usage may be exercised Interval value must conform to [ISO-8601] as represented in [W3CXMLSCHEMA]. For example, “P7D” indicates a 7 day period.
system device An identifiable computing system For example, identifiable via the CPU or unique hardware address.
version The scope of versions for the asset For example, Single Paperback, or Multiple Issues. This may be used to express [PLUS] semantics.
virtualLocation Specification of a digital locale For example, an Internet domain or IP address range

Vocabulary terms in the below table may be used as attribute in the attribute “operator” of the Constraint Entity.

Table 4: Terms for the attribute “operator” of the entity Constraint
Identifier Semantics
eq The “Equals” operator indicating that a given value equals the rightOperand of the Constraint
gt The “Greater Than” operator indicating that a given value is greater than the rightOperand of the Constraint
gteq The “Greater Than or Equal To” operator indicating that a given value is greater than or equal to the rightOperand of the Constraint
hasPart The “Has Part” operator indicating that a given value contains the rightOperand of the Constraint
isA The “Is A” operator indicating that a given value is an instance of the rightOperand of the Constraint
isAllOf The “Is All Of” operator indicating that a given value is all of the rightOperand of the Constraint
isAnyOf The “Is Any Of” operator indicating that a given value is any of the rightOperand of the Constraint
isNoneOf The “Is None Of” operator indicating that a given value is none of the rightOperand of the Constraint
isPartOf The “Is Part Of” operator indicating that a given value is contained by the rightOperand of the Constraint
lt The “Less Than” operator indicating that a given value is less than the rightOperand of the Constraint
lteq The “Less Than or Equal To” operator indicating that a given value is less than or equal to the rightOperand of the Constraint
neq The “Not Equal To” operator indicating that a given value is not equal to the rightOperand of the Constraint

2.4 Party and Role

For the Role entity, the Function and Scope attributes may be used for specific details undertaken by the identified Party in the policy.

Vocabulary terms in the below table may be used as the attribute “function” of the Role Entity.

Table 5: Terms for the attribute “function” of the entity Role
Identifier Semantics Comment
assigner The Party is the issuer of the policy statement Must be supported.
assignee The Party is the recipient of the policy statement Must be supported.
attributedParty The Party to be attributed May be specified as part of the attribute action.
consentingParty The Party to obtain consent from May be specified as part of the obtainConsent action.
informedParty The Party to be informed of all uses May be specified as part of the inform action.
payeeParty The Party is the recipient of the payment May be specified as part of the pay action.
trackingParty The Party is the usage tracker May be specified as part of the acceptTracking action.

The scope attribute indicates how to interpret the identified Party and provides contextual information in determining the extent of the policy statement. For example, if a Party is identified as a member of the Acme Social Network (using identifier urn:acme:user:billie) and they are the assignee with “allConnections” scope, then the group of individuals that have actually been assigned the permission consists of all the first-level connections (eg friends) that the identified Party has on that social network. That is, the social graph of the party starting from urn:acme:user:billie.

Vocabulary terms in the below table may be used as the attribute “scope” of the Role Entity.

Table 6: Terms for the attribute “scope” of the entity Role
Identifier Semantics Comment
individual The Party is a single individual Must be supported.
group The Party represents a defined group with multiple individual members Must be supported.
all All the collective individuals within a context For example, may be used to indicate all the users of a specific social network the party is a member of. Note that “group” scope is also assumed.
allConnections All the first-level connections of the Party For example, may be used to indicate all “friends” of the Party. Note that “group” scope is also assumed.
all2ndConnections All the second-level connections of the Party For example, may be used to indicate all “friends of friends” of the Party. Note that “group” scope is also assumed.
allGroups All the group connections of the Party For example, may be used to indicate all groups that the Party is a member of. Note that “group” scope is also assumed.

For the entity Party, it is recommended to use established standards for the party description such as [VCARD].

2.5 Asset and Relation

For the Asset entity, the Relation attributes must be used to specify the relationship of the Asset the the Policy.

Vocabulary terms in the below table may be used as the attribute “relation” of the Relation Entity.

Table 7: Terms for the attribute “relation” of the entity Relation
Identifier Semantics Comment
target The Asset upon which the Action is performed This is the default value and must be supported. Only one target can be specified.
output The Asset which is created from the output of the Action For example, can indicate that a Translated Asset uses a specific UID. This UID of the newly created Asset can then be used in other Policy expressions.

For the entity Asset, it is recommended to use established standards for the asset description such as [DC] or other standards relevant for the asset type.

3. Profiles (Informative)

The ODRL Core Model and Common Vocabulary represent the basic needs for policy expressibility. As a result, different communities will require less or more terms from the Common Vocabulary. Community Profiles that extend the ODRL Core Model or Common Vocabulary are expected to be developed that adequately document these changes in respect to the Common Vocabulary. Some requirements of this process include:

    • Document any additions to the Core Model and Common Vocabulary.
    • Document which aspects of the Core Model or Common Vocabulary are not being used (deprecated)
    • Declare your communities namespace (see Encoding specifications)
    • Share the Community Profile with the ODRL Initiative for feedback and comments

Acknowledgements

The editors gratefully acknowledge feedback and contributions to this document from:

  • All members of the Version 2.0 Group
  • Especially, Alapan Arnab, Rüdiger Grimm, Steven Rowat, Eetu Louma, Myles Stuart, Francis Cave, Helge Hundacker, Daniel Pahler, Andreas Kasten, Jonas Zitz, Jean-Noel Colin, Hassan Abdel-Rahman

References

[ODRL-MODEL] R. Iannella & S. Guth & D. Paehler & A. Kasten (eds). Open Digital Rights Language (ODRL) Version 2.0 – Core Model. Final Specification, W3C ODRL Community Group. http://www.w3.org/community/odrl/two/model/

[ODRL-11]R. Iannella (ed). Open Digital Rights Language (ODRL) Version 1.1. W3C Note, 19 Sept 2002. http://www.w3.org/TR/odrl/

[ODRL-REQ]S. Guth & R. Iannella (eds). Open Digital Rights Language (ODRL) Version 2.0 Requirements (Working Draft), ODRL Initiative, http://www.w3.org/2012/09/odrl/archive/odrl.net/2.0/v2req.html, 24 November 2004.

[RFC-2119]Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. The Internet Society, March 1997. ftp://ftp.rfc-editor.org/in-notes/rfc2119.txt

[VCARD]F. Dawson & T. Howes, vCard MIME Directory Profile, IETF, RFC 2426,September 1998. http://www.ietf.org/rfc/rfc2426.txt

[DC]The Dublin Core Metadata Intitiative http://dublincore.org

[PLUS]Picture Licensing Universal System (PLUS) Technical Specification http://ns.useplus.org

[ISO-4217]ISO 4217 currency and funds name and code elements http://www.currency-iso.org/iso_index/iso_tables.htm

[BCP-47]Tags for Identifying Languages. IETF Best Current Practice, September 2009 http://www.rfc-editor.org/rfc/bcp/bcp47.txt

[ISO-8601]ISO 8601 – Representation of dates and times http://www.iso.org/iso/date_and_time_format

[P3P]The Platform for Privacy Preferences 1.0 (P3P1.0) Specification. W3C Recommendation 16 April 2002http://www.w3.org/TR/P3P/

[W3CXMLSCHEMA]XML Schema Part 2: Datatypes Second Edition. W3C Recommendation 28 October 2004http://www.w3.org/TR/xmlschema-2/

Post Revisions: