I'm sure you've thought this through much more thoroughly than I, so I'm wondering if you can explicate this for me. Our end goal is to have a system in which the Guidelines, customization files, and non-TEI languages are expressed in PureODD, and all our processing chains work at least as well as they do now, right? But once we have the various processing working so that we can define one datatype using <dataSpec> and refer to it from a content model or attribute definition (or macro specification) with <dataRef>, why wouldn't we define them all that way? I realize that getting all our processing working is a tall order, as there is lots to do and some of it is very hard (or, at least, way beyond me). But if it works for one datatype, why not all? The answer might involve the fact that we're trying to build processing that can simultaneously handle *either* impure ODD or Pure ODD. While this seems nice to me, it doesn't strike me as a requirement. So perhaps I'm asking "why do we need co-existence?" If users are told "use all old or all new style ODD, submit old style to this process, new style to that process", I have no real problem with that. I guess I'm fuzzy on why co-existence is easier than big bang. If you could focus my lens on this, I'd appreciate it.

yes, if you want to go for co-existence you need all macroSpec and new dataSpec coexisting in the same name pool.

I dont think we are ready for a big bang conversion