[tei-council] facsKey agayne
laurent.romary at loria.fr
Tue Feb 9 11:44:17 EST 2010
This would also bring even more simplicity...
Le 9 févr. 10 à 17:36, Martin Holmes a écrit :
> Also, while we're looking at this issue, I'd like to include another
> thing that's been confusing me. Why do we have
> @target = 1–∞ occurrences of data.pointer
> @targets = 2–∞ occurrences of data.pointer
> It seems to me that @target is all we need, since it can handle any
> number of pointers. Am I missing something?
> I think any attribute that holds at least one data.pointer might as
> hold 1–∞ of them.
> Martin Holmes wrote:
>> Sebastian Rahtz wrote:
>>> On 9 Feb 2010, at 15:40, James Cummings wrote:
>>>> I think someone should post a summary of the issue to TEI-L for
>>>> wider discussion.
>>> I was waiting for more thoughts; I dont want to look too stupid on
>>> ("hi" to all those people reading this list via Google anyway….)
>>>> Would this also mean that other places we have say a @ref and a
>>>> @key that we might deprecate @key in favour of optionally using
>>>> @ref in this manner as well?
>> I really like this idea in principle. IIRC, there isn't yet a formal
>> method of deprecating an element or attribute, though, is there?
>> We also need to think about @cRef here. I've used that on occasion,
>> have been caught (by Syd, naturally) failing to supply "a canonical
>> reference from a scheme defined in a refsDecl element in the TEI
>> header", as I'm supposed to. If we're encouraging the use of custom
>> protocols in @facs and elsewhere, do we also want to encourage or
>> require some equivalent documentation of a method for discovering the
>> actual destination of the pointer?
> Martin Holmes
> University of Victoria Humanities Computing and Media Centre
> (mholmes at uvic.ca)
> Half-Baked Software, Inc.
> (mholmes at halfbakedsoftware.com)
> martin at mholmes.com
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
More information about the tei-council