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