Codelist RDDL

["Paul Spencer" <paul.spencer@boynings.co.uk>]

Ken,

I can't comment on the RDDL itself, but I have the following comments on the content (content of web page in black, my comments in blue):

Under this policy, the following are examples of backwards compatible changes that would not result in assignment of a new namespace URI:

• addition of new global element, attribute, complexType and simpleType definitions

This only works if the new global component is optional anywhere that it is used.

• addition of new elements or attributes in locations covered by a previously specified wildcard

This only works if the new element or attribute would be covered by the previously specified wildcard. This would not be the case if the new element or attribute were in the codelist namespace and the wildcard specified content in another namespace (as the current cases do to make the schema deterministic). In fact, I can't imagine a case where this could ever work if we are sticking to a single namespace (per version).

• modifications to the pattern facet of a type definition for which the value-space of the previous definition remains valid or for which the value-space of the preponderance of instance would remain valid

I'm not sure about the "or for which ..." part. This means that you are allowing an incompatible change based on guesswork of how people are using genericode.

• modifications to the cardinality of elements for which the value-space of possible instance documents conformant to the previous revision of the schema would still be valid with regards to the revised cardinality rule

OK.

 

Presumably we are talking about the set of documents conforming to the new schema being a superset of the set conforming to the old schema. Or to put it another way, any document that would validate to the old schema will validate to the new one. Except we are not quite saying this.

Regards

Paul Spencer
Director
Boynings Consulting Ltd
http://boynings.co.uk