[tei-council] EDW90 proposals (1 of several)

[James Cummings]

Sebastian Rahtz wrote:
>>Really good point. The problem is that "they", the folks who use
>><witness>, already have sigil= in P4. So it's not a question of
>>letting "them" have a special name, it will be viewed more as taking
>>away the special name currently available.
> If @sigil *is* a normal ID, there is no argument, it must be @xml:id.
> Unless James can argue his case in full court.

Under P4 @sigil is datatype CDATA.  And "indicates the sigil for one 
witness or for one group of witnesses to which readings are assigned 
in a critical apparatus".  Indicating the sigil, to me, doesn't mean 
the same thing as providing an element ID.  Is it possible, for 
example, for a well-known standard sigil to comprise of something 
which doesn't form a proper @xml:id?

The notes to <witness> instead point to one of the uses of @id on this 
as the sigil: "In local encoding schemes, the value of the id 
attribute can be used as the sigil, and the declared value of the wit 
attribute may be changed to IDREF, so as to ensure that only witnesses 
referred to in a <witness> element contained within a <witList> may 
occur in the value of any wit attribute on a reading element within an 
apparatus."  This implies to me that there are also instances where 
one wouldn't want @id to be used as the sigil. Although this 
validation is useful (and what @id is meant for) providing this 
validation is not the point of the @sigil attribute.  It just strikes 
me that the sigil attribute is used to record a sigil, which may, or 
may not, be the same as an @id.

In addition, as Syd says, it seems like P5 (which provides such 
benefits for manuscript encoding) then would be removing the ability 
to record a sigil.  <witness xml:id="MS123"> doesn't mean the
same thing as <witness sigil="123"> or <witness xml:id="MS123" 
sigil="123">.

But I've not really given it any serious thought yet, and as I said, 
I'm willing to be convinced.

-James