[tei-council] TEI model classes future directions
sebastian.rahtz at oucs.ox.ac.uk
Wed May 24 04:45:09 EDT 2006
Syd Bauman wrote:
> Classes that behave differently must be named differently. *Must*.
> value of methods= class looks like class name
> ----- -- -------- ----- ----- ---- ----- ----
> [none,default,always] a | b | c C
> sequence a, b, c C.seq
> sequence-optional a?, b?, c? C.seq-opt
> sequence-repeatable a+, b+, c+ C.seq-rep
> sequence-repeatable-optional a*, b*, c* C.seq-opt-rep
agreed. the precise naming convention may need some
worrying at. possibly a prefix not a suffix? since we already
use model.X.Y for things
> I think this is fine. I think even better would be to skip the
> methods= attribute, and just generate all 5 classes for every class
could do, yes.
> is that two different classes would
> behave entirely differently when accessed similarly
I entirely agree. I did suggest that, and I was wrong.
> I also really have a problem with the order of all the "sequence"
> methods -- the order would be the order in which the <elementSpec>s
> occur in ... in the combined P5 source and customization ODD?
the precise behaviour when a customization comes into
play isn't clear to me yet. I agree, its a serious concern.
> What if
> I want to add element E to class C in my customization: is it added
> in the spot where E is declared in the P5 source, or where I change
> that declaration to include <memberOf key="C"/>? Either way, it would
> be nice to give me control. I just haven't thought of a reasonable
> way to do that, though.
thats about where I am too. I can't see an elegant
way of controlling order.
> I hope this is making sense.
yes. and my apologies for implying you were entirely
against the idea!
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