Good. Another knock-down argument in favour of solution (d) is that as things currently stand, the stylesheets work as you might expect. (Once you've modified the content model of <datatype> to permit dataRef rather than macroRef, of course). So it doesn't require any further development work by the artist formerly known as Stormageddon. On 26/06/15 17:30, Syd Bauman wrote:
I am somewhat inclined towards (d) myself. (And I don't remember being in favor of dropping <datatype>.)
Of course, we still may have chaos when a <datatype> permits multiples of a <dataRef> which itself refers to a <dataSpec> that permits multiples.
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"
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived