The W3C ODRL Community Group publishes a Draft Specification to indicate that the document is believed to be stable and to encourage implementation by the wider community. The W3C ODRL Community Group expects to advance this document to Specification once demonstrable interoperability has been achieved. Discussion 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).

1. Overview

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”, “MAY”, “REQUIRED”, and “OPTIONAL” in accordance to [RFC2119]. Lowercase wording is used in this document.

2. Namespace and Identifiers

This Namespace URI must be used to uniquely identify ODRL Version 2.0 core model elements.

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 URI Namespace.

To enable compact URIs, this encoding also supports the use of Qualified Names (QNames) [XML-NAME] for the specification of the value identifiers. 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.

3. XML Encoding

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 contains the following attributes:

uid – a URI/Qname/Qcode (required)

type – a URI/Qname/Qcode (required)

conflict – fixed enumeration (defined in XML Schema)

undefined – fixed enumeration (defined in XML Schema)

inheritAllowed – a boolean

inheritFrom – a URI/Qname/Qcode

inheritRelation – a URI/Qname/Qcode

The Policy element contains the following elements:

permission – (required)

prohibition

The Asset and Relation association class are merged into a single Asset element to represent both the Asset and how it is related to the Permission/Prohibition/Duty. The Asset element contains the following attributes:

uid – a URI/Qname/Qcode

relation – a URI/Qname/Qcode

id – an local identifier for this element

idref – a reference to an Asset element

The cardinality of the Asset element attributes MUST be either:

uid (required), relation (required), id (optional)

idref (required)

The Party and Role association class are merged into a single Party element to represent both the Party and the role to the Permission/Prohibition/Duty. The Party element contains 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.

4. XML Linking

4.1 XML Elements

To support repeating the same element content across Permissions and Prohibitions, the Asset, Party, Constraint, Action, and Duty elements support the id and idref attributes. Any of these element that has been identified using the id attribute can then be referred to by an element with the same name using the idref attribute. In this case, the referring element must have no other content. As shown in the below example, the Prohibition refers to elements defined in the Permission, except for the Constraint element. In this case, the assignee can play the music asset in Italy but not in France.

Note that there is an important distinction when using this feature with the Duty element which also has the uid attribute. The uid attribute is used to refer to the same Duty from multiple Permissions. In this case the Duty has to be performed only once to gain access to all the Permissions. When using the id and idref attributes then the semantics change as in this case the Duty must be performed for each time it is referenced (potentially, many times). Note that the use of the uid and id attribute for the same Duty element is not permitted.

4.2 Inline Assets

In some scenarios, the Asset of an ODRL Policy maybe also be XML or HTML markup. In these 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 may 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.

6. Other Examples

6.1 W3C Privacy Rulesets

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:

Sharing, with attributes to scope the extend of sharing to; internal, affiliates, unrelated-companies, public

6.2 Open Data Commons

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.

6.3 ODRL over XMPP

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.

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.)

Appendix-A. XML Schema (Normative)

The XML Schema for ODRL Version 2.0 is shown below.

To support extensibility and reuse all the elements and their respective datatypes are global. Additionally, the elements have been defined to include xs:any element and xs:anyAttribute attribute from any (non-odrl) namespace. Note that to support the id/idref attributes some of the attributes that would normally be mandatory are now optional. They must be mandatory when not referring to an element using an idref attribute.

<p>This specification was published by the <a href="//www.w3.org/ community/odrl/”">W3C ODRL Community Group</a>. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the <a href="//www.w3.org/ community/about/agreements/ cla/”">W3C Community Contributor License Agreement (CLA)</a> there is a limited opt-out and other conditions apply. Learn more about <a href="//www.w3.org/ community/”">W3C Community and Business Groups</a>.</p>

<p>This specification was published by the <a href="//www.w3.org/ community/odrl/">W3C ODRL Community Group</a>. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the <a href="//www.w3.org/ community/about/agreements/ cla/”">W3C Community Contributor License Agreement (CLA)</a> there is a limited opt-out and other conditions apply. Learn more about <a href="//www.w3.org/ community/”">W3C Community and Business Groups</a>.</p>

<p>The W3C ODRL Community Group publishes a Draft Specification to indicate that the document is believed to be stable and to encourage implementation by the wider community. The W3C ODRL Community Group expects to advance this document to Specification once demonstrable interoperability has been achieved. Discussion of this document takes place on the W3C ODRL Community Group mailing list (see <a href="http:// lists.w3.org/ Archives/Public/ public-odrl-contrib/ ">Contributor Archive</a>). Feedback from the public is encouraged and can be send to <a href="mailto: public-odrl@w3.org">public- odrl@w3.org</a> (see <a href="http:// lists.w3.org/ Archives/Public/ public-odrl/">Public Archive</a>).</p>

<p>The <a href="//www.w3.org/ community/odrl/">W3C ODRL Community Group</a> 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 <a href="//www.w3.org/ community/odrl/">W3C ODRL Community Group</a> as appropriate for widespread deployment and that promotes the Community Groups's mission.

</p>

<p>

Discussion and feedback of this document takes place on the W3C ODRL Community Group mailing list (see <a href="http:// lists.w3.org/ Archives/Public/ public-odrl-contrib/ ">Contributor Archive</a>). Feedback from the public is encouraged and can be send to <a href="mailto: public-odrl@w3.org">public- odrl@w3.org</a> (see <a href="http:// lists.w3.org/ Archives/Public/ public-odrl/">Public Archive</a>).</p>

<P>The ODRL Version 2.0 language is defined by the ODRL Model <a href="#section- References">[ODRL-MODEL] </a> and ODRL Common Vocabulary <a href="#section- References">[ODRL-VOCAB]</a> in an abstract manner to capture the semantics of the expression, without any specific syntax and/or encoding method.

<P>The ODRL Version 2.0 language is defined by the ODRL Model <a href="#section- References">[ODRL-MODEL] </a> and ODRL Common Vocabulary <a href="#section- References">[ODRL-VOCAB]</a> in an abstract manner to capture the semantics of the expression, without any specific syntax and/or encoding method.

</P>

</P>

<p>This document describes how to encode both the Model and Common Vocabulary, including any community developed Profiles, using the XML syntax <a href="#section- References">[XML]</a> with XML Schema <a href="#section- References">[XML-SCHEMA]</a> and XML Schema Datatypes <a href="#section- References">[XML- SCHEMA-DT]</a></p>

<p>This document describes how to encode both the Model and Common Vocabulary, including any community developed Profiles, using the XML syntax <a href="#section- References">[XML]</a> with XML Schema <a href="#section- References">[XML-SCHEMA]</a> and XML Schema Datatypes <a href="#section- References">[XML- SCHEMA-DT]</a></p>

<P>This document utlilises the key words "MUST", "MAY", "REQUIRED", and "OPTIONAL" in accordance to <A href="#section- References">[RFC2119]</A>. Lowercase wording is used in this document.</P>

<P>This document utlilises the key words "MUST", "MAY", "REQUIRED", and "OPTIONAL" in accordance to <A href="#section- References">[RFC2119]</A>. Lowercase wording is used in this document.</P>

<p>This Namespace URI must be used to uniquely identify ODRL Version 2.0 core model elements. </p>

<p>This Namespace URI must be used to uniquely identify ODRL Version 2.0 core model elements. </p>

<p>Examples in this document will use <b>"o"</b> as the prefix for this Namespace. However, any prefix may be utilised as long as it is associated with the correct URI Namespace. </p>

<p>Examples in this document will use <b>"o"</b> as the prefix for this Namespace. However, any prefix may be utilised as long as it is associated with the correct URI Namespace. </p>

<P>To enable compact URIs, this encoding also supports the use of Qualified Names (QNames) <a href="#section- References">[XML-NAME]</a> for the specification of the value identifiers. In addition, Qualified Codes <a href="#section- References">[Q-CODE]</a> may also be used for vocabulary values. QCodes are similar to QNames but also allow numeric values as the first characters of the value.

<P>To enable compact URIs, this encoding also supports the use of Qualified Names (QNames) <a href="#section- References">[XML-NAME]</a> for the specification of the value identifiers. In addition, Qualified Codes <a href="#section- References">[Q-CODE]</a> may also be used for vocabulary values. QCodes are similar to QNames but also allow numeric values as the first characters of the value.

</p>

</p>

<H2><A name="section-3"></A>3. XML Encoding</H2>

<H2><A name="section-3"></A>3. XML Encoding</H2>

<p>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.</p>

<p>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.</p>

<p>The Policy element contains the following attributes:</p>

<p>The Policy element contains the following attributes:</p>

<ul>

<ul>

<li>uid - a URI/Qname/Qcode (required)</li>

<li>uid - a URI/Qname/Qcode (required)</li>

<li>type - a URI/Qname/Qcode (required)</li>

<li>type - a URI/Qname/Qcode (required)</li>

<li>conflict - fixed enumeration (defined in XML Schema)</li>

<li>conflict - fixed enumeration (defined in XML Schema)</li>

<li>undefined - fixed enumeration (defined in XML Schema)</li>

<li>undefined - fixed enumeration (defined in XML Schema)</li>

<li>inheritAllowed - a boolean </li>

<li>inheritAllowed - a boolean </li>

<li>inheritFrom - a URI/Qname/Qcode</li>

<li>inheritFrom - a URI/Qname/Qcode</li>

<li>inheritRelation - a URI/Qname/Qcode</li>

<li>inheritRelation - a URI/Qname/Qcode</li>

</ul>

</ul>

<P>The Policy element contains the following elements:<p>

<P>The Policy element contains the following elements:<p>

<ul>

<ul>

<li>permission - (required) </li>

<li>permission - (required) </li>

<li>prohibition </li>

<li>prohibition </li>

</ul>

</ul>

<p>The Asset and Relation association class are merged into a single Asset element to represent both the Asset and how it is related to the Permission/Prohibition/Duty. The Asset element contains the following attributes:</p>

<p>The Asset and Relation association class are merged into a single Asset element to represent both the Asset and how it is related to the Permission/Prohibition/Duty. The Asset element contains the following attributes:</p>

<ul>

<ul>

<li>uid - a URI/Qname/Qcode</li>

<li>uid - a URI/Qname/Qcode</li>

<li>relation - a URI/Qname/Qcode</li>

<li>relation - a URI/Qname/Qcode</li>

<li>id - an local identifier for this element</li>

<li>id - an local identifier for this element</li>

<li>idref - a reference to an Asset element</li>

<li>idref - a reference to an Asset element</li>

</ul>

</ul>

<p>The cardinality of the Asset element attributes MUST be either:</p>

<p>The cardinality of the Asset element attributes MUST be either:</p>

<ol>

<ol>

<li>uid (required), relation (required), id (optional)</li>

<li>uid (required), relation (required), id (optional)</li>

<li>idref (required)</li>

<li>idref (required)</li>

</ol>

</ol>

<p>The Party and Role association class are merged into a single Party element to represent both the Party and the role to the Permission/Prohibition/Duty. The Party element contains the following attributes:</p>

<p>The Party and Role association class are merged into a single Party element to represent both the Party and the role to the Permission/Prohibition/Duty. The Party element contains the following attributes:</p>

<ul>

<ul>

<li>uid - a URI/Qname/Qcode</li>

<li>uid - a URI/Qname/Qcode</li>

<li>function - a URI/Qname/Qcode</li>

<li>function - a URI/Qname/Qcode</li>

<li>scope - a URI/Qname/Qcode </li>

<li>scope - a URI/Qname/Qcode </li>

<li>id - an local identifier for this element</li>

<li>id - an local identifier for this element</li>

<li>idref - a reference to a Party element</li>

<li>idref - a reference to a Party element</li>

</ul>

</ul>

<p>The cardinality of the Party element attributes MUST be either:</p>

<p>The cardinality of the Party element attributes MUST be either:</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<H2><A name="section-4"></A>4. XML Linking</H2>

<H2><A name="section-4"></A>4. XML Linking</H2>

<H3><A name="section-41"></A>4.1 XML Elements</H2>

<H3><A name="section-41"></A>4.1 XML Elements</H2>

To support repeating the same element content across Permissions and Prohibitions, the Asset, Party, Constraint, Action, and Duty elements support the <b>id</b> and <b>idref</b> attributes. Any of these element that has been identified using the <b>id</b> attribute can then be referred to by an element with the same name using the <b>idref</b> attribute. In this case, the referring element must have no other content. As shown in the below example, the Prohibition refers to elements defined in the Permission, except for the Constraint element. In this case, the assignee can play the music asset in Italy but not in France.

To support repeating the same element content across Permissions and Prohibitions, the Asset, Party, Constraint, Action, and Duty elements support the <b>id</b> and <b>idref</b> attributes. Any of these element that has been identified using the <b>id</b> attribute can then be referred to by an element with the same name using the <b>idref</b> attribute. In this case, the referring element must have no other content. As shown in the below example, the Prohibition refers to elements defined in the Permission, except for the Constraint element. In this case, the assignee can play the music asset in Italy but not in France.

Note that there is an important distinction when using this feature with the Duty element which also has the <b>uid</b> attribute. The <b>uid</b> attribute is used to refer to the same Duty from multiple Permissions. In this case the Duty has to be performed only once to gain access to all the Permissions. When using the <b>id</b> and <b>idref</b> attributes then the semantics change as in this case the Duty must be performed for each time it is referenced (potentially, many times). Note that the use of the <b>uid</b> and <b>id</b> attribute for the same Duty element is not permitted.

Note that there is an important distinction when using this feature with the Duty element which also has the <b>uid</b> attribute. The <b>uid</b> attribute is used to refer to the same Duty from multiple Permissions. In this case the Duty has to be performed only once to gain access to all the Permissions. When using the <b>id</b> and <b>idref</b> attributes then the semantics change as in this case the Duty must be performed for each time it is referenced (potentially, many times). Note that the use of the <b>uid</b> and <b>id</b> attribute for the same Duty element is not permitted.

<H3><A name="section-42"></A>4.2 Inline Assets</H2>

<H3><A name="section-42"></A>4.2 Inline Assets</H2>

<p>

<p>

In some scenarios, the Asset of an ODRL Policy maybe also be XML or HTML markup. In these 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 may 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.

In some scenarios, the Asset of an ODRL Policy maybe also be XML or HTML markup. In these 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 may 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.

The <a href="http:// dev.w3.org/2009/ dap/privacy- rulesets/">W3C Privacy Rulesets</a> 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: </p>

The <a href="http:// dev.w3.org/2009/ dap/privacy- rulesets/">W3C Privacy Rulesets</a> 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: </p>

<p>The <a href="http:// www.opendatacommons.org/">Open Data Commons</a> provides a number of licenses for the sharing of open databases. One example is the <a href="http:// www.opendatacommons.org/licenses/ odbl/summary/">Open Database License (ODbL) v1.0</a> which enables you to "share, create, and adapt" the database as long as you "attribute, share-a-like, and keep open" the outcomes.</p>

<p>The <a href="http:// www.opendatacommons.org/">Open Data Commons</a> provides a number of licenses for the sharing of open databases. One example is the <a href="http:// www.opendatacommons.org/licenses/ odbl/summary/">Open Database License (ODbL) v1.0</a> which enables you to "share, create, and adapt" the database as long as you "attribute, share-a-like, and keep open" the outcomes.</p>

<p>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.</p>

<p>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.</p>

<p>The Extensible Messaging and Presence Protocol <a href="#section- References">[XMPP-CORE] </a> 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:</p>

<p>The Extensible Messaging and Presence Protocol <a href="#section- References">[XMPP-CORE] </a> 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:</p>

<ul>

<ul>

<li>Directly from the sender to a single recipient or a list of recipients (using <a href="http:// xmpp.org/extensions/ xep-0033.html">Extended Stanza Addressing</a>)

<li>Directly from the sender to a single recipient or a list of recipients (using <a href="http:// xmpp.org/extensions/ xep-0033.html">Extended Stanza Addressing</a>)

<p>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.</p>

<p>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.</p>

<p>The following example shows "Scenario 4.4 Request" sent as a direct message from the requester to the asset owner.</p>

<p>The following example shows "Scenario 4.4 Request" sent as a direct message from the requester to the asset owner.</p>

<p>XMPP is used by a number of distributed Social Networks, such as <a href="http:// onesocialweb.org/ ">OneSocialWeb</a>. 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. </p>

<p>XMPP is used by a number of distributed Social Networks, such as <a href="http:// onesocialweb.org/ ">OneSocialWeb</a>. 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. </p>

<p> To support extensibility and reuse all the elements and their respective datatypes are global. Additionally, the elements have been defined to include <b>xs:any</b> element and <b>xs:anyAttribute</b> attribute from any (non-odrl) namespace. Note that to support the <b>id/idref</b> attributes some of the attributes that would normally be mandatory are now optional. They must be mandatory when not referring to an element using an <b>idref</b> attribute.

<p> To support extensibility and reuse all the elements and their respective datatypes are global. Additionally, the elements have been defined to include <b>xs:any</b> element and <b>xs:anyAttribute</b> attribute from any (non-odrl) namespace. Note that to support the <b>id/idref</b> attributes some of the attributes that would normally be mandatory are now optional. They must be mandatory when not referring to an element using an <b>idref</b> attribute.