[tei-council] 4 questions about TD

Sebastian Rahtz sebastian.rahtz at oucs.ox.ac.uk
Fri Jun 2 11:30:36 EDT 2006

Lou Burnard wrote:
> 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? 
A classSpec is no more than a null definition anyway.

I'd say that by definition, class declararions are what the "tei"
module is actually for.  However, if a class is only
used in a given module, it can be declared there - we have
34 examples of this already! eg model.persnamePart

> 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. 
a moduleSpec itself is just a "null definition", of course
> 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)
good question. II think you need to jump one way or the author,
and follow the consequences. I dont think there is any meaningful
difference - they are "macros" in a general CS sense, but implemented
as RNG "patterns"
> 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?
interesting point. pragmatically, I'd suggest leaving sleeping
dogs alone, keep the @type attribute, and say that errors
should be raised.

maybe one would declare att.foo, with no attributes, as a placeholder
for someone else to add some?
> 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>
slightly discouraging? why not say that an ODD processor _must_
implement the rule that the order is dependent on the order
in which the classSpecs are defined in the source?

Sebastian Rahtz      

Information Manager, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

OSS Watch: JISC Open Source Advisory Service

More information about the tei-council mailing list