[tei-council] nym/@parts

[Martin Holmes]

As a general rule, whenever you create a fixed array of a size you think 
is more than anyone could need, a need immediately arises for more. 
One-to-infinite is easier than explaining why a limit exists at all. I 
vote for change.

Cheers,
Martin

On 12-02-01 03:31 PM, Lou Burnard wrote:
> Nope, don't remember why. Presumably someone thought, not implausibly,
> that allowing more than 100 values was rather silly, as James suggests.
>
>
> On 01/02/12 23:06, Martin Holmes wrote:
>> At first I thought it must be a typo -- someone copying from
>> one-to-infinity on another attribute and misreading it as 1-100 -- but
>> SVN says different:
>>
>> ------------------------------------------------------------------------
>> r2418 | louburnard | 2007-05-07 14:36:57 -0700 (Mon, 07 May 2007) | 2 lines
>>
>> removing @old on handShift; allowing up to 100 targets for nym at parts
>>
>>
>> Lou, do you remember why?
>>
>> Cheers,
>> Martin
>>
>> On 12-02-01 02:39 PM, James Cummings wrote:
>>>
>>> Hiya,
>>>
>>> In reading through things (and correcting non-schema things
>>> relating to an old bug assigned to me) I happened to notice:
>>>
>>> http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/ws/Guidelines-web/en/html/ref-nym.html
>>>
>>> The @parts attribute on<nym>    is limited to 1 - 100 occurrences
>>> of data.pointer.  Although I can't picture a good use case for
>>> more than 50 myself... there are plenty of places where we allow
>>> 1 - infinity pointers as an attribute value.  Why are we so
>>> specific that there can't be more than 100 on nym/@part in specific?
>>>
>>> I ask this in full knowledge that I have hazy recollection of
>>> being part of the working group that introduced<nym>, but no
>>> recollection of the seemingly arbitrary limit in itself.
>>>
>>> Just curious,
>>>
>>> -James
>>>
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)