On Aug 26, 2011, at 2:54 PM, Martin Holmes wrote:
> On 11-08-26 05:42 AM, Sebastian Rahtz wrote:
>>> One way to do this would be with namespaces. Elements deemed to contain
>>> only transcription could be in a separate namespace from elements
>>> containing interpretive data or metadata.
>> it's not impossible we could allow any attribute to also appear as a child
>> element in a separate namespace. But I suspect a total rewrite with the
>> idea of considerably lessening use of attributes would be cleaner.
> I thought what he was basically saying was that _if_ this separation were rigid:
> - elements (in <text> at least) contain transcribed content
> - attributes contain editorial/interpretive/metadata content
> then indexing and searching the original text would be much simpler.
I try to guess at the design principles behind TEI, seen as an XML application. To me it looks as if this separation is one of the guiding principles, though I don't believe I have ever heard anyone say so. Following discussions on the list, it appears to be second nature to the TEI community.
The principle is not maintained 100%, however, one exception being figDesc. Now, to exclude a handful of elements from an index is really not that big a problem, whence the parenthesis: this is not my main point.
I ask myself, why is this principle not maintained fully, e.g. in figDesc, and the answer I arrive at is that - obviously - nested elements (<name>, for instance) are called for in a figDesc, and an attribute cannot accommodate these.
Are there then any other considerations that could tempt TEI to open up an element instead of an attribute? Well, the existence of repetitions could be one such consideration, so when I read about ideas to make @type have lists as their value, my reaction was, why not make @type a repeatable element? We can change @type in the way suggested by Sebastian, sure, but then we would have to discipline ourselves and get around things like <name type="ethnic group chinese">, since we obviously only want two values there: underscores and all kinds of ways to convert white space would then be forced upon us. (Actually, in our project, we have already made @subtype contain a list - but I will not reveal here which clunky workaround we use.)
Combining the first and the second strand of thought, I ask whether there might not be use cases for having nested contents in @type as well, and I propose some simple ones involving @resp and @cert, offering ways of interpretation that I would like to have the means to express in TEI - and which I claim that others would find a use for as well.
At the back of my mind is the fact, indisputable I think, that anything an attribute can do, an element can do equally well or better. (I am here talking about schema-controlled element-only documents - attributes have some of the functionality of a schema, limiting your input in various ways.)
I know that this is a can of worms, and I am grateful that these thoughts of mine are even taken seriously, when so much more important matters are on the agenda, but perhaps it helps to know where the constraints come from, even if TEI is by now a juggernaut that makes a fundamental change of direction impossible.
> However, this would make it impossible to use helpful markup inside editorial interpolations, and there are other issues, such as supplied expansions:
> <abbr>Brd</abbr> <--- original content
> <expan>Board</expan <--- supplied, but should be indexed anyway
No, there would be nothing to hinder you from marking up with <contents> anything you wish included in an index on <text>.
<abbr><contents>Brd</contents></abbr> <--- original content
<expan><contents>Board</contents></expan <--- supplied, but indexed anyway
One could also have <contents> of different levels, conditionally called in.
> The use of distinct namespaces would solve this problem.
Yes, one could also use namespaces to control this.
>> I like Jens' thinking, but its a whole big can of worms to open...
>> 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