Mandatory prohibition in XML Encoding??

ODRL Group:

 

This summer some language was added to the ODRL Core Model
(http://www.w3.org/community/odrl/work/2-0-core-model-constraint-draft-chang
es/#section-2) to clarify the context of policies including this sentence
"Based on that context, an ODRL Policy must contain at least one Permission
and may contain Prohibitions."

 

This clarifies the context and fits into a wider context but the
implementation of <o:permission> as a mandatory element in the XML Encoding
appears to be wrong:

-          The Inheritance design of ODRL
(http://www.w3.org/community/odrl/work/2-0-core-model-constraint-draft-chang
es/#section-211) outlines that policy document B could be a child of policy
document A inheriting its permissions and prohibitions. 

-          By that design it could be the case that policy document A
defines a permission and policy document B adds only a prohibition

-          This meets the basic rule for a policy as the full policy is the
union of the policy documents A and B - and this union meets the rule of a
mandatory permission.

-          But how to tackle the mandatory <permission> element in policy
document B if a permission doesn't make sense in this context?

 

Therefore IPTC proposes to remove the "required" cardinality of <permission>
in the XML Encoding document - and points at the JSON Encoding document
which does not include a required permission. It would make sense to add a
note to both Encoding specifications that if the full policy is made of
multiple documents only a (virtual) union of them has to meet the "one
permission is required" rule of the Core Model and not each policy document.

 

Thank you,

 

Michael

 

Michael Steidl

Managing Director of the IPTC [mdirector@iptc.org]

International Press Telecommunications Council 
Web:  <http://www.iptc.org/> www.iptc.org - on Twitter
<http://www.twitter.com/IPTC> @IPTC

Business office address: 

25 Southampton Buildings, London WC2A 1AL, United Kingdom

Registered in England, company no 101096

 

Received on Wednesday, 5 November 2014 18:07:16 UTC