[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