[tei-council] Re: on spec grp 2, datatypes normalized

[Christian Wittern]

Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> writes:

>>On Specification group 2: Datatypes: normalised
>>-- ------------- ----- -- ---------- ----------
>>
>>* tei.data.temporal (I like the name better than the previous clumsy
>>  "temporalExpression"): the change removes the capability to express
>>  a time without seconds. The change also brings the datatype closer
>>  in line with being "normalized" to W3C Schema part 2, in the sense
>>  that the only component whose value space is not a date or time has
>>  been removed.
>>  
>>
>
> This is indeed the case, and reflects a conscious decision to use
> attribute values here as elsewhere to represent a normalized value,
> which might indeed be represented in a more nuanced way within the
> content of the element or by linking elsewhere.
> ....
>
>>
>>  Rather than suggest TEI should require precision to the second, I'm
>>  actually surprised that someone hasn't suggested, for consistency
>>  at least, that TEI should permit precision only to the hour. (After
>>  all, pending this discussion we permit precision to the year,
>>  month, day, minute, and second.)
>>
>>  
>>
> I don't get it. If you want to give a value precise to only a year,
> month etc. you  can do so using the approved designation, surely?
> "1900" doesnt mean any particular time in 1900, it just means
> 1900. Similarly, 1900-12 means some time in December 1900. And so
> on.

It is a timespan, put not a point in time.  This problem raises its
head regularily when trying to express a Chinese year in ISO, which
should then be rendered as 1900-02-17 to 1901-01-29.  Any idea how
this could be expressed on @value for date?

> Similar considerations apply to the other two cases you mention. In
> the case of duration and sex, we are talking about an encoded value
> for an attribute, and it makes much better sense to use an ISO- or
> W3C- 
> recommended encoded value than to make one up.  "Readability" of
> syntax is a very subjective question which in my view should be given
> correspondingly less weight. Obviously in any real application the
> actual values stored in the attribute won't be visible to the end-user
> anyway: they will be translated into something more friendly.

Well, I grudgingly agree to this now, we probably do the best to
long-term maintability if we stick with these unwieldy ISO things --
they will hopefully stay around for a while.

Alll the best,

Christian

-- 

 Christian Wittern 
 Institute for Research in Humanities, Kyoto University
 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN