[tei-council] 4 questions about TD
wittern at kanji.zinbun.kyoto-u.ac.jp
Fri Jun 2 19:30:49 EDT 2006
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
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".
Institute for Research in Humanities, Kyoto University
47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN
More information about the tei-council