[tei-council] tei stemma model

[David J Birnbaum]

Dear Conal (cc Council),

I certainly appreciate the advantage of using consistent attributes 
across the TEI spectrum, so using @xml:id to mark an element as a target 
of pointing, @n as a name, and something else as a pointer to other 
elements will strike a usefully familiar note with users of other parts 
of P5. In my own projects, though, I try to be zealous about reducing 
the opportunity for error, so I avoid markup like <node n="blah" 
xml:id="blah" key="blah" ident="blah">blah</node>, where the values of 
all of the attributes should be the same, since that creates an 
opportunity for an inattentive user to fail to keep them in sync, or to 
write a pointer on another element to the wrong attribute.

For what it's worth, I do most of my schema development directly in 
Relax NG, I like the added power of Schematron rules, and I tend to care 
most about producing the most constrained schema possible. (Thus my 
ongoing losing battle in Council against repeatable or groups!) Weighing 
this worthwhile goal against the worthwhile goal of using global 
attributes (such as @n or @xml:id) consistently throughout the TEI is 
tricky, and my preferences may ultimately differ from those of the rest 
of Council.

I have no objection to someone taking what I've developed and changing 
the attribute usage before integrating it into P5. It isn't the way I'd 
encode a stemma, since I think it invites error unnecessarily, but as 
long as the primary functionality (nesting typed nodes and a mechanism 
for encoding contamination through XML containment) is there, the rest 
is just reference validation, and assuming the user is attentive, either 
model will get job done.

Best,

David

Conal Tuohy wrote:
> On Tue, 2007-07-17 at 09:56 -0400, David J Birnbaum wrote:
>   
>> 1) Every <node> needs an identifier, to which @target can point.
>>
>> 2) <node> elements might also want to be able to point to 
>> <msDescription> elements elsewhere, either in the same document or in a 
>> different document.
>>
>> 3) Every <node> needs a label that can be rendered, and that cannot be 
>> subject to character restrictions.
>>
>> 4) One could use a different attribute in each of these functions, but 
>> since they are all related (they are all essentially names of a 
>> manuscript represented by a node), using three attributes where one 
>> would do the job not only is inefficient, but also creates opportunities 
>> for inconsistency (i.e., error).
>>     
>
> OK I figured it was this consideration (parsimony) that was the
> motivation, and that makes sense. I think there's something to be said
> for using a reference system that's more consistent with the others used
> in TEI, and keeping the label function distinct from the reference
> function.
>
> What about pointing TO stemma nodes from elsewhere? Might that not be
> needed? And if so, wouldn't that really require use of @xml:id? I think
> the advantage of @xml:id as a reference point is that it is defined in a
> broader context (i.e. as part of the XML spec rather than in a TEI
> schema) and can be used by non-schema-aware processors.
>
>   
>> 5) In the schema I present, the one attribute that I use has all the 
>> desired properties of IDs, IDREFs, and plain text names simultaneously. 
>> There are no character restrictions on the name, it is guaranteed to be 
>> unique, and @target is guaranteed to point to the name of a <node>.
>>
>> I'm not sure whether my reasoning was unclear or whether Council 
>> understands it but disagrees. In the former case, I hope the preceding 
>> elaboration is helpful (and if it is still unclear, please ask!). In the 
>> latter, if Council understands the reasoning but nonetheless believes we 
>> should use three attributes instead of one, so be it.
>>     
>
> Well, yes, I guessed that was the justification (which does make sense),
> but I think personally I would prefer the use of distinct @n and @xml:id
> attributes, and tei:contaminates/@target having the type "URI". Is it
> just me being picky?
>
> Cheers
>
> C
>