on spec grp 2, datatypes normalized (was "Re: [tei-council] datatypes")

[Lou Burnard]

Syd Bauman wrote:

>It seems to make sense to divide these comments up along with the
>clever groupings Lou has used. Thus this one is
>
>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.

>  All that said, if we do go with the EDW90 recommendation of
>  permitting times to the minute, the prose should note that it is
>  possible that some processors might not be able to properly compare
>  or sort them. (Unlikely, though, as the W3C algorithm for doing so
>  applies to times without seconds as well as with; see 3.2.7.4.)
>
>  
>
Surely, the point of using this format is precisely that as many 
processors as possible will do the right thing with them. Can you give 
some examples of processors which do not behave correctly when handling 
ISO 8601 format values? And is there any reason to believe they would 
make a better fist of handling an arbitrary TEI-invented format instead?

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.