[tei-council] Dates and calendars

[Martin Holmes]

Lou says:

> My first thought was that @calendar by definition tells you how to
> interpret the content of the <date>. Ergo if there is no content, but
> there is a @when (or, for that matter, a @when-custom), specifying
> @calendar can only lead to confusion. The @calendar value does NOT apply
> to either @when or @when-custom (or you would not be able to supply both)

Here's my problem with that: att.datable.custom provides "attributes for 
normalization of elements that contain datable events to a custom dating 
system (i.e. other than the Gregorian used by W3 and ISO)."

In other words, if you use @when-custom and friends, it's because the 
calendar is not Gregorian.

So somewhere you have to specify what that calendar is. The obvious 
place is in @calendar. This is especially important if there is no 
workable conversion between the calendar in use in the host element and 
the Gregorian (as in the case of Anno Mundi dates, for instance, about 
which there is potential disagreement to the extent of 1500 years).

So I think it's important to be able to use @calendar whenever you use 
@*-custom, and @calendar SHOULD be taken to refer to the values of 
@*-custom. In other words, I think the definition of @calendar should be 
expanded thus:

"indicates the system or calendar to which the date represented by the 
content of this element, and/or the dates expressed in attributes from 
att.datable.custom, belong."

Without this, there's no way to provide a formal link from a date like this:

<date when-custom="3050"/>

to a calendar (e.g. Anno Mundi). You can say that we should do this:

<date when-custom="3050" calendar="#anno_mundi">3050</date>

which is true, but the value of the custom attribute is that it can be 
constrained according to known rules (documented in <calendar>) and 
therefore processed. And it's surely perverse to say that in this 
situation, the @calendar refers to the text content, but NOT to the 
@when-custom attribute, when the purpose of the @when-custom attribute 
is to allow you to encode non-Gregorian dates in a formal way.

So I think we should expand @calendar as suggested above.

Cheers,
Martin

On 12-08-14 12:57 PM, Lou Burnard wrote:
> On 14/08/12 19:13, Gabriel Bodard wrote:
>> On 2012-08-14 16:31, Martin Holmes wrote:
>>>> What is this schematron supposed to be constraining? No @calendar if
>>>> <date> (etc) is empty?
>>> I think so. That should be true, shouldn't it?
>>
>> I'm not clear what an empty <date> means, myself, so I'm not sure I can
>> imagine what the danger of allowing @calendar on it is. Is the idea that
>> @calendar should only be used when the date is used in transcription of
>> a primary text?
>
>
> I think (with some trepidation, having already got  several things wrong
> on this thread) that an empty <date> is to a <date> with content like a
> <ptr> is to a <ref>. You might want to have your software generate the
> content for the date, you might not actually want any content at all.
> But you do want to reference a date.
>
> My first thought was that @calendar by definition tells you how to
> interpret the content of the <date>. Ergo if there is no content, but
> there is a @when (or, for that matter, a @when-custom), specifying
> @calendar can only lead to confusion. The @calendar value does NOT apply
> to either @when or @when-custom (or you would not be able to supply both)
>
>
> So the rule should be something like "if a <date> is empty, then either
> @when or @when-custom (or both) should be supplied AND  @calendar must
> NOT be supplied"
>
>
>>>>> No *-custom without @datingPoint|@datingMethod?
>>> I had thought so, but then I realized I wouldn't want to enforce either
>>> of those things. If @calendar points to a <calendar> with a detailed
>>> description of the dating system, then there's no point in @datingMethod
>>> (which also "supplies a pointer to a <calendarDesc> element or other
>>> means of interpreting the values of the custom dating attributes".
>>> (Incidentally, should that be <calendarDesc> or just <calendar>?)
>
> See above. I think this is based on the mistaken assumption that
> @calendar refers to the value of the attributes on <date> rather than to
> its content.
>
>
> This would all be much easier if there were some clear examples of how
> to use these various things in combination in the Guidelines...
>
>>> Similarly, @datingPoint is obviously optional.
>
> Yes. Though I do wonder why it is not treated as a kind of calendar.
>
>>>
>>> However, I think it's true to say, isn't it, that if you have any of
>>> @*-custom, you should have one of @calendar, @datingMethod or @datingPoint?
>>
>> Yes, that is almost certainly true.
>
> Almost, but I think not quite. @calendar doesn't help you interpret your
> @*.customs much.
>
> So is the rule, report @*-custom
>> without @calendar|@datingPoint|@datingMethod? That seems responsible,
>> although I'm one of those people who often uses sloppy behaviour in
>> practice that would fall foul of this.
>>
>> I worry a bit about the two above rules being a bit contradictory,
>> though. We don't complain about @*-custom on an empty element; but we do
>> complain about @*-custom without @calendar|@dP|@dM, so I add @calendar
>> to make it valid, and it then complains about @calendar on the empty
>> element. (Maybe @calendar has no bearing on @*-custom at all, though?)
>>
>
> exactly!
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)