To play devil's advocate, the following seems perfectly reasonable to me. <macroSpec mode="change" ident="data.certainty" module="tei" type="dt"> <content> <rng:choice> <rng:value>medium</rng:value> <rng:value>low</rng:value> <rng:value>unknown</rng:value> </rng:choice> </content> <remarks versionDate="2015-06-11" xml:lang="en"> <p>Reduced certainty may be expressed by <val>medium</val> or <val>low</val>; at the FUN project we do not use the TEI's <val>high</val> value (the certainty is presumed <val>high</val> unless this attribute is specified).</p> <p>The value <val>unknown</val> should be used ...</p> </remarks> </macroSpec> Also, it kinda runs against my "it should be in a container" instinct to put the content-defining elements directly in <dataSpec>, rather than in some wrapper, itself a child of <dataSpec>.

Since datatypes are relatively simple and easy to duplicate, I agree that it makes sense to have a rule that you can't modify an existing one.

...

I had proposed defining dataSpec without any wrapper element for the parts of it which actually define the datatype itself i.e. with an (alternate|dataRef|valList) in its content model. Sebastian points out, reasonably enough, that this makes life difficult for someone wishing to modify or change the "content" of an existing dataSpec, and is not consistent with our previous practice. I take the point, but find it hard to imagine anyone wanting to write an ODD which would modify one of our existing datatypes, when defining a new one with a different name would be much simpler and more transparent. Indeed, maybe you shouldnt be allowed to modify existing datatypes.

Thanks to Sebastian's much-appreciated late night activity, the Pure ODD branch on SF (P5-Pure) now has a test file and we have a test implementation to test....

yours in purity