[tei-council] logical madness in class attribute inheritance

Gabriel Bodard gabriel.bodard at kcl.ac.uk
Tue Jul 24 06:43:23 EDT 2012


Presumably the correct way to resolve this is to have the other classes 
(other than att.typed, I guess), be members of but modify att.typed, by: 
omitting @subtype; making @type rec rather than opt; etc.?

On 2012-07-24 09:20, Sebastian Rahtz wrote:
> We have 4 attribute classes which define the attribute "type":
>
> ../Source/Specs/att.entryLike.xml:    <attDef ident="type" usage="opt">
> ../Source/Specs/att.interpLike.xml:    <attDef ident="type" usage="rec">
> ../Source/Specs/att.textCritical.xml:    <attDef ident="type" usage="opt">
> ../Source/Specs/att.typed.xml:    <attDef ident="type" usage="opt">
>
> This is, frankly, bonkers. An element can freely be a member of all four classes,
> and then what?
>
> I have met this while fixing the local override of class attributes, and
> find that if an element is in both classes, and overrides @type, I have no idea which one
> it is overriding!
>
> Sadly, I have thereby got the P5 build in a broken state because of ambiguities
> here.
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> Sólo le pido a Dios
> que el futuro no me sea indiferente
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


More information about the tei-council mailing list