[tei-council] action item -- due Tuesday -- reminder

[James Cummings]

Comments interspersed

Syd Bauman wrote:
> Responsibility: all
> Action: read & comment on SB's post "date attributes: summary,
>         problems, and some suggestions"[1]
> Due date: 2006-02-06

> First, a listing of the attributes that are directly involved with
> dating. ("dating" as in "timing", not as in "courtship"  :-) 

<snip/>

> Problems
> --------
> * Some are distressed by the fact that attributes that are of the
>   same datatype (data.temporal) and serve similar functions have
>   different names, in particular:
>       value=  of  <date>, <time>, <distance>, and <docDate>
>       date=   of  <birth>, <change>, and <death>
>   I am not bothered by this in the least, because I think the
>   semantics are clearer with these names, and the combined
>   alternative (dateValue=) is at least cumbersome if not misleading
>   (i.e., on <time>).
>   Suggestion: leave names as they are. 

Agreed. It does bother me that it is date/@value but birth/@date; but
birth/@value is misleading and birth/@dateValue just seems silly.

> * We haven't implemented classes as well as we could.
>   Suggestions: 
> 
>   - Put <docDate> into att.datePart. This has the disadvantage of
>     giving <docDate> a dur= attribute, but I'm not sure it is worth
>     making another class just for this one case. Thoughts?

Agreed.

>   - Create a new attribute class for the date= of <birth>, <death>,
>     and <change>. (Any suggestions for the name?) 

Is att.dateLike taken?

>   - If we keep <distance>[1] we may wish to reconsider its class
>     membership, as value= is a bit silly on <distance>. It needs only
>     dur= from att.datePart, making two cases that benefit from
>     splitting att.datePart. (See <docDate>, above.)

Erm. I'm in favour of keeping it, specifically as measure for spatial uses.
<distance>two miles</distance>  It isn't just for temporal distance, remember.

> * The precision= attribute is superfluous, as the precision is
>   represented in the value of the value=, dur=, notBefore=, notAfter=,
>   from=, or to= attribute(s).
>   One might argue that we should instead change this attribute to
>   indicate that a time is precise only to the minute or hour (as
>   opposed to second or fraction thereof) and thus not require our
>   extension to W3C datatypes. However, this may become a non-issue
>   depending on outcomes of the items discussed below; besides, I
>   wouldn't make this argument, so ...
>   Suggestion: delete it.

I could live with that.

> * Users want a method of expressing things like "Oct 27 of 1909, 1910,
>   or 1911" or "an Oct 27, but I don't know which one". The W3C format
>   that express only a month and day explicitly (xsd:gMonthDay) means
>   "a set of one-day long, annually periodic instances". These users
>   don't want the entire set, they want only one. ISO 8601:2004 does
>   not seem to have even a method to represent the set, let alone a
>   singleton. (James, can you verify that? How would one represent
>   month & day, no year, in 8601?)

Well early ISO 8601 drafts allowed --12-25 for any Christmas Day... which I
think we've included in our pattern, and isn't that what xsd:gMonthDay does?  Or
am I missing something?

>   Suggestion: I haven't got one, thus defer to P5 1.1.

The multiple dates thing is a 'choice' if Dan gets an expanded notion of choice
into P5 1.1....

<snip/>

> Choosing one of these requires some thought and discussion. Up front I
> can only say that I don't like the 'attribute level' solution. It's
> just too confusing for the average user, most of whom have little or
> nothing to gain. I.e., to borrow a phrase from Perl, while it does
> make the hard things possible, it does not make the easy things easy.
> The others all do, presuming we make simple format dates the default
> for the class or datatype level.

I don't really like the attribute or the all-in-one solutions proposed, which I
guess leaves me with the Class or Datatype ones.  Of these, it seems that the
datatype solution puts the least burden on the user for understanding what is
going on.

-James

-- 
Dr James Cummings, Oxford Text Archive, University of Oxford
James dot Cummings at oucs dot ox dot ac dot uk