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

On 26/06/15 17:32, Syd Bauman wrote:

...

... teidata.pointer Why are we changing its name from "data.pointer" to "teidata.pointer" just because it's defined differently? Are you keeping both definitions for some reason? I vaguely remember having this conversation a few weeks ago, with the upshot being "it takes work to convert to the new system". Am I remembering that correctly?

Yes, that sounds about right! When we started the exercise, the hope was to be able to maintain the two systems in parallel, just for caution's sake. The more I do it, however, the less convinced I am that this is actually necessary.