[This is a re-post of what I sent 09-12 18:20, which may not have been posted.] Lou -- Overall this looks very good, and thanks for putting in all that effort. Three things I either don't understand correctly, or (if I do), I'm a bit uncomfortable with. * The basic underlying plan, if I grok correctly, is to use an <elementRef> with an @key of "anyElement" at the point in a PureODD model that any element is allowed. The definition of "anyElement", I presume, would itself allow any element with any attributes with any content. If I have this right, the overloading of the value of @key makes me nervous. (It overloaded because it has two definitions: 1) "the identifier used for the required element within the source indicated", and 2) a special keyword which means something completely different (any XML element with any XML content), and precludes the use of an element actually named <anyElement>.) This smacks to me of magic or voodoo, which we are supposed to shun. Why not an <anyElement/> or <anyXML/> element? * The <elementRef> does not currently have an @include, but it seems that supplying a namespace on this new attribute restricts the allowed elements. I guess there is an argument to be made that this is analogous to including elements from a module, but I'm worried that users may find this a bit confusing. (Can I supply 2 or more namespaces?) * If we're using <elementRef> instead of macro.anyXML, why does macro.anyXML need to be re-defined (as in section 6); or is that new definition the definition of <elementRef key="anyElement"/>? In either case, why is a text node allowed as a child (but only after an element)? I don't think we're going to need macro.anyXML at all in the new universe, but if we do, this content model seems screwy. But I may be missing something.