[tei-council] 4 questions about TD

[Christian Wittern]

Syd Bauman <Syd_Bauman at Brown.edu> writes:

>> 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.)

My vote is to allow classes to spring to life wherever they want.

>> 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.

I'd rather stay with macroSpec throughout, reserving patterns to
specific RNG usage.

>> 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?)

Since when is TEI shy of redundancies?  While maybe not technically
necessary, I'd say it is good to have the @type to remind yourself
that what kind of thing you are working on.  Having <attList> as the
sole indicator does not seem sound to me. 

>> 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.

My vote is for "take the sequence things are defined in as default,
modify it with the mechanism suggested by John".

best, chw

-- 

 Christian Wittern 
 Institute for Research in Humanities, Kyoto University
 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN