[tei-council] comments on edw90

[Lou Burnard]

Syd Bauman wrote:

>
>The idea from Paris was that a <valList>, whether closed, open, or
>semi, is required for an attribute of type tei.data.token. I still
>think that's fine.
>
>
>  
>
No, I think the presence of a valList implies that the datatype should 
be tei.data.enumerated, which maps onto either an explicit list of 
alternatives (if the valList is closed) or onto tei.data.token otherwise.


>  
>
>>I dont quite see what you're getting at here. We need to decide
>>whether sex is an enumeration of possible values (possibly allowing
>>people to use their own values), or a hardwired datatype like date
>>values. My vote, fwiw, is for the former, but I'm open to
>>discussion.
>>

...

>>This is simply reiterating a decision we took at the Council meeting
>>in Oxford, if I remember aright.
>>    
>>
>
>If you say so ... but which was the antecedent of "This"?
>
>
>  
>

That datatypes should all be mapped to xsd: datatypes

>>>If we're going to use W3C datatypes, then at least in those cases
>>>where W3C puts the unit in with the quantity (xsd:duration
>>>explicitly, and the various date and time formats implicitly) we'd
>>>have to do the same.
>>>      
>>>
>
>  
>
>>Yes., but only if we chose to. We could say we will NEVER have
>>attributes which combine in their value quantity+unit, or we could
>>say we have some which do and some which dont, or we could say all
>>quantities have the potential to include units. Again, a list of
>>specific cases might help sharpen discussion and reach a decision.
>>    
>>
>
>Right, but my point was that the choice is inextricably linked to the
>use of xsd:duration and xsd:[time-and-date-types]. If we make use of
>those (and I can't really see not doing so at this point ... maybe
>someday we could write a better datatype library, but it would be an
>effort) then we can't choose "NEVER".
>
>  
>

So the choice is really

(1)  use xsd:duration (which includes units) , and thus remove all the 
additional attributes that specify units

(2) use plain old numeric dataype of some sort, and retain the unit 
attribute

Choice (1) is only going to work for durations where we can be confident 
that the xsd units are going to meet TEI needs, obviously. I fear there 
may be fewer of these than anticipated -- probably people will be 
content to use SI units for times, but you can bet someone will always 
want to measure (e.g.) distance in rods poles and perches.

At present the only attributes assigned tei.data.duration are age= and 
dur=  Choice 1 fits fine with the latter, and reasonably well with the 
former, imho. Any others?