RE: Updated ODRL in JSON DRAFT

To throw into this discussion the versioning policy at IPTC:
- major version number: are increased only for really substantial changes -
what exactly makes a change substantial is a matter of discussion, but we
apply them quite rarely.
- minor version numbers: is increased for any change in the specifications.
But we collect changes and then issue a new release of the standard with a
bunch of them and a new version number

The guidelines for a namespace are:
- should be as persistent as possible
- a change of the ns is only needed if a change to the specs makes the new
one not backward compatible.
Backward compatibility is defined as: processors aligning with a newer
version of a standard must be able to process any document instance aligning
to an older version of the standard.
Rule of thumb: any additions do not require a new namespace, deletions or
changes (e.g. of property names) require one.

I hope this helps to take a decision regarding the next version of ODRL.

My personal note:
- we should be aware that the change of the ODRL namespace for properties is
a quite substantial formal change, any ODRL 2.1 processor will not be able
to process 2.0 policies.
- I see no need to reflect changes like for this version in a new namespace
.../21/

Michael

Michael Steidl
Managing Director of the IPTC [mdirector@iptc.org]
International Press Telecommunications Council 
Web: www.iptc.org - on Twitter @IPTC
Business office address: 
25 Southampton Buildings, London WC2A 1AL, United Kingdom
Registered in England, company no 101096



> -----Original Message-----
> From: Mo McRoberts [mailto:Mo.McRoberts@bbc.co.uk]
> Sent: Tuesday, June 03, 2014 9:15 AM
> To: Renato Iannella
> Cc: ODRL Community Group (Contrib)
> Subject: RE: Updated ODRL in JSON DRAFT
> 
> > So we would not then really use the current URI
> (http://www.w3.org/ns/odrl/2/)
> > instead we would go to final versions using
> http://www.w3.org/ns/odrl/21/
> >
> > Cheers...
> > Renato Iannella
> 
> I would still use /ns/odrl/2/, because that's a URI which is only used by
> anything 'new' (i.e., the RDF, the harmonised XML namespace, etc.)
> 
> I would further suggest that any post-harmonisation changes which actively
> break (rather than simply marking as deprecated) anything are given a new
> major version number and new URI -- although I would tend to avoid doing
> that in practice anyway. Changes which introduce new terms or are
> otherwise backwards-compatible should have a new minor version number,
> to allow conformance reporting (e.g., "this application understands ODRL
2.4
> or earlier fragments"), but maintain /ns/odrl/2/.
> 
> M.
> 
> --
> Mo McRoberts - Chief Technical Architect - Archives & Digital Public
Space,
> Zone 2.12, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA,
> MC3 D6, BBC Media Centre, 201 Wood Lane, London W12 7TQ,
> 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E

Received on Tuesday, 3 June 2014 07:54:24 UTC