Re: [codelist] Codelist RDDL

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2007-07-24 17:44 +0100, Paul Spencer wrote:
>I can't comment on the RDDL itself, but I have the following 
>comments on the content

The content is boilerplate from:

   http://docs.oasis-open.org/templates/rddl.html

... and I have included it unchanged except for the reference to genericode.

>(content of web page in black, my comments in blue):

(I cannot support colour in my response)

>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.

I agree.

>    * 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.

I believe that is what it says.

>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).

Point taken.

>In fact, I can't imagine a case where this could ever work if we are 
>sticking to a single namespace (per version).

Not sure what you mean by that.

>    * 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.

I do not know what it means ... Mary?  My first read was just that 
old instances validate against new constraints.  But I can see now 
the word "preponderance" as if to imply "not all".

>    * 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.

Yes, any instance of, say, a version 1.3 is a valid instance of version 1.4.

There is a good discussion of both forwards and backwards compatibility here:

   http://www.w3.org/2001/tag/doc/versioning-20070326.html

>Except we are not quite saying this.

Can you recommend wording for Mary to consider changing in the boilerplate?

Mary, can you comment on Paul's observations?

Thanks for bringing this up, Paul.

. . . . . . . . . . . Ken

--
Upcoming public training: XSLT/XSL-FO Sep 10, UBL/code lists Oct 1
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds:     publicly-available developer resources and training
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Jul'07  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal