[tei-council] 4 questions about TD

[Sebastian Rahtz]

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
http://www.oss-watch.ac.uk