[tei-council] TEI model classes future directions

[Syd Bauman]

> I posed the question of whether we want the TEI to extend the
> meaning of model classes beyond its current meaning of a set of
> alternates. ... Syd has argued (unfortunately not in a message to
> the Council - maybe you can repost your thing about sets/lists
> here, Syd?) that it's a slippery slope of confusion.

Not quite an accurate representation of my (not very well-formed)
opinion. I think extending the capability of classes is a Good Thing,
with a caveat. 

Classes that behave differently must be named differently. *Must*.
That means the system has to enforce it, we can't rely on the editors
to do it right. Your current suggestion, Sebastian, if I have it
right, is to have a methods= attribute on <classSpec>. On processing,
each <classSpec> would generate a "normal" class (alternating), plus
one class for each distinct value of methods=, something like as
follows: 

 value of methods=		class looks like    class name
 ----- -- --------		----- ----- ----    ----- ----
 [none,default,always]		a | b | c           C
 sequence			a, b, c             C.seq
 sequence-optional		a?, b?, c?          C.seq-opt
 sequence-repeatable		a+, b+, c+          C.seq-rep
 sequence-repeatable-optional   a*, b*, c*          C.seq-opt-rep

I think this is fine. I think even better would be to skip the
methods= attribute, and just generate all 5 classes for every class
declared, but that's a minor difference that can be hammered out.

What I think is a slippery slope leading eventually to fire and
brimstone coming down from the skies; rivers and seas boiling; 40
years of darkness, earthquakes, volcanoes; the dead rising from the
grave; human sacrifice; dogs and cats, living together; mass hysteria
-- sorry, got carried away -- is that two different classes would
behave entirely differently when accessed similarly (i.e., when named
the same). I.e. having

  model.C = a | b | c
  model.D = x, y, z

is icky, whereas having

  model.C = a | b | c
  model.D.seq = x, y, z

is lovely. That is what I thought you were recommending at first,
which is why I cried foul. The current suggestion is going to be a
rarely used but very powerful capability.


I also really have a problem with the order of all the "sequence"
methods -- the order would be the order in which the <elementSpec>s
occur in ... in the combined P5 source and customization ODD? What if
I want to add element E to class C in my customization: is it added
in the spot where E is declared in the P5 source, or where I change
that declaration to include <memberOf key="C"/>? Either way, it would
be nice to give me control. I just haven't thought of a reasonable
way to do that, though.


I hope this is making sense.