RE: odrl-ISSUE-6: XML Schema Extensibility

From: Myles, Stuart 
Sent: Tuesday, March 20, 2012 11:57 AM
To: 'Renato Iannella'; ODRL Community Group WG
Subject: RE: odrl-ISSUE-6: XML Schema Extensibility

 

Hi Renato,

 

I think most would agree that any kind of change to the Core Model is to be
avoided, unless we find a very significant problem at this point. So, I
agree with you that allowing the assets and constraints to have IDs (and so
be referenced) could let us have more concise ODRL instance documents.

 

On the other hand, I think that it is wise to consider ways to make the
schema representation of the model more extensible. (I found this discussion
http://snee.com/xml/xml2005/industryschemas.html quite helpful as a way of
seeing how to make various XML Schema more "open" to extension. And, in
fact, I followed a lot of that advice in opening up IPTC's NITF
http://stuartmyles.blogspot.co.uk/2010/11/adding-foreign-namespace-support-t
o.html). So, I think that Jim's suggestion of making some changes to the way
that the XSD is structured are worth considering, if they make ODRL easier
to work with (by allowing ODRL to be more easily combined with other XML
namespaces).

 

For example, why not make permission and prohibition "gloabal" elements,
rather than local? At present, the ODRL XSD follows the "Russian Doll
Pattern" http://www.xfront.com/GlobalVersusLocal.html#FirstDesign where the
schema structure mirrors the instance document structure, i.e. permissions
and restrictions can only appear within a policy element. On the other hand,
making the elements global lets people make use of the ODRL elements in
other ways, but still lets you control what is a valid ODRL document
http://www.xfront.com/GlobalVersusLocal.html#SecondDesign.

 

Regards,

Stuart

 

 

 

From: Renato Iannella [mailto:ri@semanticidentity.com] 
Sent: Friday, March 16, 2012 8:53 AM
To: ODRL Community Group WG
Subject: RE: odrl-ISSUE-6: XML Schema Extensibility

 

In relation to ISSUE-6 [1] - there are two parts to the issues raised in
Jim's blog [2]:

 

 1 - the manner in which the current XML Schema is declared to capture the
semantics of the Core Model.

 2 - modifications to the Core Model to be more extensible.

 

A number of the comments under Point 3 (in [2]) fall into the second
category.

These propose changes to the Core Model, such as an Asset in each Permission
(Bullet Point#1).

 

We have discussed the Core Model now for a number of years (!) and I think
that it has reach a level of maturity that most are happy with.

And unless it is broken, then I would not consider changing it now.

This may mean that the XML produced is verbose - but if there is something
the model cannot not support, then we should consider these (at this point
in the development of V2.0)

 

However - there could be a solution if the main issue is repeating elements
(such as asset and constraint).and that is to follow the Duty model and
allow these elements to have IDs, and then reference them?

 

As for point 1) above, we can of course change the XML Schema to be more
extensible.

Is the main scenario to support additional elements within the core entities
(such as asset, permission etc?)

We can also change the string datatype (used in rigthOperand) to something
more suitable?

 

 

Cheers...

Renato Iannella

Semantic Identity

 <http://semanticidentity.com> http://semanticidentity.com

Mobile: +61 4 1313 2206

 

[1] http://www.w3.org/community/odrl/track/issues/6

[2]
<http://jims-thoughtspot.blogspot.com/2012/01/first-look-at-odrl-v2.html>
http://jims-thoughtspot.blogspot.com/2012/01/first-look-at-odrl-v2.html

 

The information contained in this communication is intended for the use
of the designated recipients named above. If the reader of this 
communication is not the intended recipient, you are hereby notified
that you have received this communication in error, and that any review,
dissemination, distribution or copying of this communication is strictly
prohibited. If you have received this communication in error, please 
notify The Associated Press immediately by telephone at +1-212-621-1898 
and delete this email. Thank you.
[IP_US_DISC]

 

msk dccc60c6d2c3a6438f0cf467d9a4938