We had agreed (fairly tentatively, but it is what Sebastian has since
implemented) that in the new scheme of things, a purified attribute
definition would simply embed a <dataRef> directly, rather than wrap it
in some as-yet-unnamed alternative to the current <datatype> element.
In testing this out against the Guidelines, I have now realised why this
was not a good idea. Of the 466 instances of <datatype> in the current
P5 source, a sizeable proportion (106) specify a @maxOccurs attribute to
indicate that the attribute can (or cannot) take multiple instances of
the datatype indicated. This can't be specified on <dataRef> itself at
present, these attributes nopt being available.
So we are left with the following choices:
a) add @maxOccurs and @minOccurs to <dataRef> and cope with the ensuing
chaos if the <dataSpec> being referenced permits multiple values
b) define a whole raft of new <dataSpec>s and <dataRef>s, one for each
combination of occurrence indicators and <dataref>, so that for example
we will have teidata.pointer, teidata.pointers,
teidata.atLeastTwoPointers etc etc.
c) invent something which behaves just like <datatype> but has a
different name and doesn't allow anything except <dataRef> as a child.
d) permit <dataRef> as a child of <datatype>
I bet smart chaps like you can tell which solution I am recommending...
just for the record, the current model for <datatype> is an alternation
of <macroRef> and "any-XML". In practice we use only the latter, as
every <datatype> has a content resembling