[tei-council] 4 questions about TD

[Syd Bauman]

> 1. Are all classes declared upfront? In other words, can a module
>    declare a new class without there being at least a null definition
>    for it in the infrastructure module? If this is the case (as I
>    sincerely hope) references throughout the text of TD to modules as
>    things which can define "elements, attributes, classes, and
>    macros" need attention.

I'm not sure which side of this issue you are hoping for, or why. My
gut instinct (without putting much thought into it) is that a module
should be able to declare a new class on its own. (I'm not sure any
TEI modules should do that, but I do think the system should permit
it.)


> 2. Are the things defined by the element currently called "macroSpec"
>    to be referred to in the text as "patterns" or as "macros"? At
>    present they appear to be referred to throughout TD as "patterns".
>    If this is the case then the spec element should be renamed to
>    "patternSpec". If it is not, then the references should be changed
>    (again). (In ST, however, we consistently talk about them as
>    "macros", probably because we also talk about "patterns" in the
>    RelaxNG sense)

Darn good question. I don't have a strong opinion at this point. It
depends in large part on how closely tied these things are to RelaxNG
patterns. If we want to think of a <macroSpec> merely as something
that we use to generate a useful RelaxNG pattern, than <patternSpec>
is probably a better name. If we'd like to stick to the idea that it
is far more generic than that, and what a <macroSpec> declares just
happens to be instantiated in RelaxNG as a pattern, then it is
probably better to avoid the confusion of calling them "patterns" in
the text or GI.


> 3. Aside from the naming convention, there are two ways in which an
>    attribute class distinguishes itself from a model class. (a) it
>    has a child <attList> (b) its @type attribute says what it is. Do
>    we need to maintain both of these? If we do, should an ODD
>    processor raise an error when it finds an <attList> inside a
>    <classSpec type="model"> or a <classSpec type="atts"> which does
>    not contain an <attList>? If we don't, which one should go?

I'm undecided on whether to keep type="atts|model" at the moment. But
if we do keep it, I think we should provide the validation that
type=atts has an <attList> and type=model does not earlier than the
ODD processor. Since ODD can't define a RelaxNG schema that can
validate this, I'd say we should do it with Schematron. (But that's
only if we keep the attribute, which does seem a bit redundant --
Sebastian, do you actually find it particularly helpful?)


> 4. What did we decide to do about sequence? I have written the
>    following in my revision of TD:
>      <p>The sequence in which members of a class appear in a content
>        model when one of the sequence options is used is dependent on
>        the ODD processor in use. It will always be the same sequence
>        for a given class reference, but is not in principle
>        user-accessible. </p>

I don't think that we did decide anything, and we should. Even if it
is the not really appealing "order specified", we need something. The
idea that it's up to the ODD processor renders the concept of a
sequential class almost useless.