Dan O'Donnell wrote:
> As I think I said here, my own believe is that choice's current model
> has been influenced partially by legacy issues. I.e. we already have a
> <abbr> and <expan> tag, so we don't have a
> <abbreviation><short_form>x</short_form><long_form>xy</long_form></abbreviation> and similar for correction, emendation, and the like.
> But in an ideal world we would construct a model where tei:choice is to
> tei:app and pseudo-tei:abbreviation and pseudo-tei:correction, as tei:ab
> is to tei:p and tei:l, and tei:seg is to tei:abbr, tei:c, and tei:w.
I think much of this discussion is a bit confused about how TEI elements
are related to each other. The phrase "syntactic sugar" has much to
answer for. Let's be clear on one thing: the primary means by which TEI
elements express their inter-relationships, or lack of them, is their
membership in TEI *model classes*. So we have a class called
model.choicePart, and all elements which can appear within a <choice>
are members of it. If you want to add <rune> to the things that can
appear within <choice>, you just add it to that class.
Now, there is also a class called model.segLike, of which <seg> <phr>
<cl> <w> and <c> are all members. And you could also add <rune> to that
Members of model.segLike have two properties in common: firstly they are
all "arbitrary segmentations" -- that is how they are semantically
related. Secondly they are structurally identical in that they can all
appear within (but not between) paragraphs. We express that by saying
that the model.segLike class is a subclass of model.phrase.
These two reasons are why we can talk of them as a class. They can also
all be mapped to a more generic encoding pf the <seg type="xxx">
variety, but that is not formally expressed, except by virtue of the
fact that all members of a class are structurally interchangeable -- you
could just as well say <w type="phr">. And, as this demonstrates, such
variations don't always make sense: <w> makes more sense as a child of
<phr> than as its parent.
The only property which all members of model.choicePart have in common
is that they can appear within <choice>.
We could have made model.seglike a subclass of model.choicePart (rather
than adding <seg> to the latter class). This would have made <c>
"chooseable", which was the original need that started this thread. It
would also have opened the door to such encodings as
at the price of enlarging the opportunities for complete nonsense.
> The problem with the current choice model in my view is that it creates
> a general class that is restricted to a few small types of children...
> or any arbitrary phrase, but noting in between. I can think of many
> other things than abbreviations and the like that can exist in
> simultaneous, alternate markup.
Certainly, and so can we all. But, as I said above, that's why the
content model is expressed using a class rather than a "few small types