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 <rng:ref name="data.foo"/>. So
proposal (d) above is arguably not really a change at all, since
<dataRef> is just syntactic sugar for <macroRef>
I'd like to move ahead on this this week, since it's holding up my
testing of the purified version of the Guidelines. Can I ask for a quick
response along the lines of EITHER "no problem" OR "hold on there I need
to think about this" by Monday??? Or of course, "You idiot what about
this completely different and much better solution"