[tei-council] encodingDesc/profileDesc and att.declarable

James Cummings James.Cummings at it.ox.ac.uk
Sun Apr 21 08:55:26 EDT 2013


Hi Council,

I was looking at bits of the teiHeader recently, in particular 
encodingDesc and profileDesc, and wondering about their 
repeatability.  In our model of the teiHeader you have to have a 
fileDesc, then zero or more model.teiHeaderPart (encodingDesc and 
profileDesc) in any mixed up orders , then optionally one 
revisionDesc.

This makes sense, of course, if we think about it because we only 
want one fileDesc and revisionDesc, and it is possible that we 
might need more than one encodingDesc and profileDesc, especially 
in a TEI file with multiple text elements. (And there is no good 
reason to restrict the order of encodingDesc and profileDesc 
elements.)

My question is then: Why don't encodingDesc and profileDesc claim 
membership in att.declarable?  This would give them the @default 
attribute to enable us to know which profileDesc or encodingDesc 
was the 'default'. Many of the children of these elements are 
declarable and so possibly the reason is that we're suppose to 
have only one of these elements and provide multiple of a 
particular child to choose from. If encodingDesc and profileDesc 
had this attribute it would enable the same mechanism on a 
greater level.

The declarable elements are discussed here:

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CC.html#CCAS2

I can't shake the feeling that I'm missing something obvious as 
to why these elements even though repeatable are not declarable. 
We've probably discussed this before and I've just forgotten. 
I'll happily file a feature request if I'm wrong, but eagerly 
wait to have the obvious reasons that I've overlooked pointed out 
to me.

Thanks,

-James

-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford


More information about the tei-council mailing list