Codelist RDDL

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