on spec grp 2, datatypes normalized (was "Re: [tei-council] datatypes")
lou.burnard at computing-services.oxford.ac.uk
Sun Sep 18 13:42:49 EDT 2005
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 18.104.22.168.)
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.
More information about the tei-council