Morning, Lou! Thanks for checking this over. On the data.foo definitions, while I don't mind reverting, seems to me it makes no practical difference at all, and I was just trying (somewhat in vain, I admit) to reduce the number of warning messages produced by a build. On "Pure ODD" vs "pure ODD", I think your reason for preferring the latter makes sense, and will happily change the one occurrence of the former so it matches the one of the latter. But coming up with a paraphrase for "pure" is a bit tougher. How about "... rather than the ODD elements defined in these Guidelines"? I agree completely that saying an unprefixed attribute "belongs" to the TEI namespace is ludicrous. We could still say "are defined by the TEI", but then of course people define their own non-TEI attributes on their own new elements in their own customizations all the time. (Or, so we hope.) I'm thinking we need to have a paragraph addressing this issue. Some cases seem pretty easy, others a little thornier. * Prefixed attrs on any element are defined by the language associated with their namespace. * An unprefixed attr that is defined by TEI GLs, and is on an element defined by TEI GLs should be considered a "TEI attribute" in some sense -- i.e. users should use such an attribute only to mean that which GLs says it means. * An unprefixed attr that is not defined by the TEI GLs, but is on an element defined by the TEI GLs should be declared and defined in the customization ODD (and has the semantics therein). We need to ask ourselves if these attributes should be forbidden, i.e. users should only create attrs in their own namespace. * An unprefixed attr that is not defined by the TEI GLs on an element that is also not defined by the TEI GLs is either defined by the customization ODD (if it's declared in there) or by the native language of the element. E.g., the @transliteration attribute on my mods:abstract element in my <xenoData> has the semantics defined by MODS. * An unprefixed attr that is defined by the TEI GLs, but is on an element that is not defined by the TEI GLs (e.g., if I have an @degree on my syd:graduate element in my document describing commencement, or an @degree on my syd:difficulty element describing a diving meet, or the @type on the mods:abstract in my <xenoData>) is a bit trickier, but I think it should be the same as above. I.e. it is either defined by the customization ODD (if it's declared in there) or by the native language of the element. Oy.
I see you already reverted the definitely erroneous change you made so that's good. However, though not erroneous, I think it's a mistake to change the content models of the data.foo macros : these should continue to use rng -- that's what distinguishes them from their teidata.foo compadre. You seem to have done this for some (data.sex springs to mind) but not the majority, so maybe you could just undo the changes to data.sex, data.enumerated, and any others I missed?
However, reviewing this text has reminded me of a couple of problems, in particular around the term "clean" which was originally conceived of in a way we don't actually support. For example, look at this:
"In a TEI-conformant document, it is assumed that all attributes not explicitly labelled with a namespace (such as, for example <att>xml:id</att>) also belong to the TEI namespace, and are defined by the TEI."
This is surely nonsense? TEI attributes are not labelled with a namespace prefix, and don't belong to any namespace. We can "consider" they are in the TEI namespace till we're blue in the face, but no parser will agree with us!
Furthermore, when someone defines a new attribute, *unless* they explicitly associate it with some other namespace, it will be in the same boat.
I am not sure what to do about this, but I don't like the fact that this chapter makes vague promises we can't enforce.
As for "Pure ODD" vs "pure ODD" -- I don't like to reify "Pure ODD" (as if there were and always would be two parallel types of ODD) so I prefer the latter. And I'd also try to replace the "pure" by some paraphrase .