calendar= should not be in att.datable

[sydb]

The @calendar attribute is currently a member of att.datable, but should not be.

This is because @calendar is, by definition, about “the date represented by the content of this element”. But among the members of att.datable we find several elements whose content is not a date (e.g., <orgName> or <unitDef>), and lots of elements whose content need not include a date (e.g., <acquisition> or <climate>).

So it is clear to Council that @calendar should split out of att.datable. There are some issues still to be resolved, however:

• should @calendar be put into a class of its own? (My vote is “yes”)
• if so, what should that class be named? (“att.dated”, maybe?)
• which elements should retain @calendar and which should lose it?

[sydb]

Personally, I feel this (@calendar in att.datable) is a corrigible error, and thus need not be deprecated. I have learned, however, that this is a controversial opinion that others do not share. Thus I am planning to put this removal through a 1-year deprecation period unless I hear support for the idea that such an egregious error can just be corrected without deprecation.

I hope I do hear “deprecation not needed”, because deprecation is quite a pain in this case. We cannot just add @validUntil to the appropriate <attDef>, because then proper @calendar attributes would get flagged, too. So to deprecate we need to remove @calendar from att.datable, and then add it back to all the members of att.datable (either directly or through 2 new classes), and add @validUntil where appropriate. Then, at the end of deprecation, we have to undo half of that.

Furthermore, my plan is that we keep @calendar only on <date>, <origDate>, and <time> (my answer to the last bullet point in previous post).

[martindholmes]

@sydb What about the syntactic-sugar date elements like <birth>, <death> and <floruit>?

[sydb]

Those three (at least) are definitively not syntactic-sugar for <date>:

<birth>: contains information about a person's birth, such as its date and place. <death>: contains information about a person's death, such as its date and place. <floruit>: contains information about a person's period of activity.

Examples from the Guidelines:

<birth when="1960-12-10">
  In a small cottage near
  <name type="place">Aix-la-Chapelle</name>,
  early in the morning of
  <date>10 Dec 1960</date>
</birth>

<death when="1960-12-10">
  Passed away near
  <name type="place">Aix-la-Chapelle</name>,
  after suffering from cerebral palsy.
</death>

Although to be fair, there are no examples of <floruit> that have other than date (or date range) content. Furthermore, there are some examples of these three that do imply the date is the important thing. E.g.:

<birth when="-0044-03-20">
  20 March 43 BC
  <placeName>
     <settlement type="city">Sulmona</settlement>
     <country key="IT">Italie</country>
  </placeName>
 </birth>

That said, I do not currently have strong feelings that they should not bear @calendar; only a mild feeling that if you need it, maybe there should be a <date> child.

[hcayless]

For the record, I think that this is absolutely a corrigible error and should not be subject to deprecation.

[lb42]

Deprecation is entirely unnecessary. It makes no sense for @calendar to be datable, unless you think decisions about which calendar is being used in a given situation might change over time,

[duncdrum]

I don’t think that the current behaviors sanity or corrigibility should be the determining factor when it comes to the question about deprecation.

If existing valid code will become invalid and require work, because of changes in this commit, those changes require a deprecation period.

If dated calendars are silly and no one uses it, then no one will mourn. But deprecation seems the way to go to me.

[sydb]

While it may not change your opinion, @duncdrum, I think you may be missing the point on two fronts.

First, the very definition of “corrigible error” (here in TEI-land) includes that no deprecation period is required.

But more importantly, although use of @calendar on, say, <orgName> may have been inadvertently permitted by the schema, it was not part of the abstract model. So correcting it in the schema is merely bringing the schema in line with the prose, as it were.

And, it is worth realizing, that the only difference to a wayward user who has used @calendar on <orgName> is as follows: With deprecation she has to change her data before she can upgrade to version 4.4.0 or 4.5.0 (or whatever). Without deprecation, she needs to change her data before she upgrades to 4.2.0.

I think that use of something like <orgName from="1532" to="1555" calendar="#whatever"> to assert that 1532–1555 is expressed in the whatever calendar instead of proleptic Gregorian (as @from and @to are defined as being in) is so egregiously problematic that the faster she changes her data the more likely she avoids significant confusion or problems.

That’s just my 2¢, though.

[martindholmes]

@sydb The example above doesn't mean what you suggest: @calendar refers to the text content of the element, not the value of dating attributes. Whether it would be wrong to say <orgName from="1532" to="1555" calendar="#whatever"> is wrong would depend on the text content of <orgName>; it has no connection with the @from and @to attributes. If I want to use a non-Gregorian calendar in dating attributes, I can do it like this:

<orgName from-custom="1532" to-custom="1555" datingMethod="#julian">

which seems perfectly fine to me, especially for calendars that don't easily convert to Gregorian.

[sydb]

Yes, @martindholmes, I know it doesn’t mean that. My point is if the mythical scholar in my example does think that, I would like to disavow her of that misunderstanding sooner rather than later.

[duncdrum]

While it may not change your opinion …

@sydb correct, it doesn’t

[martindholmes]

With @sydb. Here's a list of elements that have it:

element	Needs @calendar?
acquisition	no
affiliation	no
age	no
application	no
binding	no
birth	no
bloc	no
change	no
climate	no
conversion	no
country	no
creation	no
custEvent	no
date	yes
death	no
district	no
education	no
event	no
faith	no
floruit	no
geogFeat	no
geogName	no
idno	no
langKnowledge	no
langKnown	no
licence	no
location	no
name	no
nationality	no
objectName	no
occupation	no
offset	no
orgName	no
origDate	yes
origPlace	no
origin	no
persName	no
placeName	no
population	no
precision	no
provenance	no
region	no
relation	no
residence	no
resp	no
seal	no
settlement	no
sex	no
socecStatus	no
stamp	no
state	no
terrain	no
time	yes
title	no
trait	no
unitDecl	no
unitDef	no

To summarize, only <date>, <time> and <origDate> need it; and we also think that <docDate> deserves both @calendar and att.datable, and its own custom @when should go away.

[duncdrum]

He is now <age calendar='sui'>2 years</age> old makes a lot of sense to me, for age descriptions in context where baby's are 1 at birth (as opposed to 0 as is the norm in english). there are probably similar arguments to be made for <state> and <trait> although i can't come up with any while still reeling from the 1 🎂 🥳

[martindholmes]

@duncdrum You're pointing at a file called "sui" containing only a <calendar> element. That can't be right, surely?

But the broader point you're raising is whether durations should be datable, as opposed to dates/datetimes/date ranges/datetime ranges. I don't know for sure, but I don't think so. Are these special years defined differently from regular years, or are they just the same years we're all familiar with? Could a reader read "2 years" and wonder to themselves "I wonder what he means by years, here; are they regular years, or something weird and different that needs documenting?"

[duncdrum]

@martindholmes they are years, it’s just that a person that is 20 years old in Canada was born in 2000, while a Chinese person was born in 2001. So in translation or other documents that go back and forth, we have to wonder all the time, how old the speaker really is.

And no I missed the # the sui calendar being explained via clendarDesc in the header.

[martindholmes]

@duncdrum But the age element says nothing about when someone was born; that's irrelevant. For it to be relevant, there would have to be mention of a date on which that person was two years old, and it's that date that may need a calendar. But in that case, you should surely use custom dating attributes, wouldn't you? @calendar is only for cases in which a true datetime is in the original text of the document.

[sydb]

But (he asked curiously of @duncdrum) is that differnce really a calendar difference, or a cultural difference?

I can, however, imagine <age calendar="#DCU_Martian">65</age> in the personographic entry for J’onn J’onzz.

Nonetheless, I am against providing @calendar on <age> barring an actual use case.

[duncdrum]

When either transcribing interviews or government documents, there are often date and and age fields or statements. The above example is very much an actual use case, I as an editor need to supply this info or otherwise the two twenty year olds interviewed by me on the same date refer to different years in their accounts.

[sydb]

If I understand you correctly, @duncdrum (and I well may not), that is an argument for being able to normalize the value in <age>, but not an argument for doing so with @calendar in particular. The difference does not seem to be one of calendar, but one of counting. (More similar to the age-old argument of whether arrays should be indexed starting from 0 or 1 — ask a C programmer and an XSLT programmer and watch the sparks fly! — than to Gregorian vs Julian, no?)

Seems to me using @type (of which "sui" is one of the suggested values) makes more sense.

And keep in mind that if someone were, for some reason, to put a date into <age>, the calendar for that date can be indicated with the @calendar of a <date> child of <age>.

[martindholmes]

@sydb for this:

<age calendar="#DCU_Martian">65</age>

you would surely use a unitDef and a unit element to specify that these years are not earth-years. A quantity of time is not a date, I don't think; it's a measurement. A calendar is a way of specifying points on a timeline, and the timeline may be divided into units of various kinds, and you may or may not specify those dates using some of those units; but the fact that (for example) a calendar year may start on Jan 1, March 1 or March 25 doesn't change the length of a day or a year.

[duncdrum]

It’s getting quite late here, I did a quick search for my use of @calendar And have found instance of quite a few of the elements in Martin’s list. Now it’s possible that I have used this wrongly, but it’s also possible that you guys are missing the point.

I ll post some excerpts from one of my projects in the next few days so we can get this sorted.

but the fact that (for example) a calendar year may start on Jan 1, March 1 or March 25 doesn't change the length of a day or a year.

@sydb it can if eg your event is on February 27. But the interview is on the next January 1st. In calendar a (that of the interviewer) we have completed one annual cycle and are in plus 1 territory, in calendar b (the interviewees) we haven’t completed the annual cycle and are still in +-0.

This is a fairly common problem in court documents between the Chinese and the British empires, when trying to determine how much time has passed between events, or when a deadline is up for e.g. returning a colony island after 99 years. Of course the official lunar calendar doesn’t always start on March 1 but on a different day every year, making this even more fun.

[martindholmes]

@duncdrum I still think you're confusing measurement with dating, but let's take a clear example for discussion. A Martian calendar is presumably delimited in Martian days (24 h 37 m 22.663 s in earth-time). If you're tagging a text written by a Martian, and they use the word "day", meaning a Martian day, in a sentence:

On that day, he was arrested.

How should we tag that word "day"? We can't tag it as a <date>, because it isn't one -- although the phrase "that day" is arguably taggable as a date, in which case, we can use @calendar on <date>, and @datingMethod etc. to explain it in detail. But if, inside there, we want to explain that the duration of that day is X number of earth-seconds, we can do that in a number of different ways, including @dur-iso on the <date> element, or by tagging the word "day" as a <unit type="time"> (used in a Guidelines example), and using @unitRef to point to an explanation of it. You might mention or point to a calendar in the <unitDef>, but it's surely possible that there are multiple Martian calendrical systems; the length of a Martian day is not a property of one specific calendar.

Let's say there is a unit of time called a blurg, which is a property of one Martian calendar alone, and it consists of 9 Martian days:

During that blurg, he was arrested.

Again, "that blurg" is a date or a date-range, and can be tagged that way. But "blurg" is still a unit, not a date. @calendar "indicates the system or calendar to which the date represented by the content of this element belongs." "blurg" doesn't represent a date, so @calendar isn't appropriate, surely?

The same applies to <age>65</age>; it's not a date, it's a quantity, and if you need to explain it you can use <measure unitRef="#martianYear">. But I don't think you can use @calendar unless you change its definition.

[duncdrum]

Part 1: Why I think that there is a problem.

As promised, here it goes. Let's ignore for a moment the xml xs:date pecularieties concerning BCE dates. And let's also forgo the detailed calendrical math stuff. The point is that documents contain dates we wish to deal with in tei.

So let's look at the OPs example:

<birth when="-0044-03-20">
  20 March 43 BC
  <placeName>
     <settlement type="city">Sulmona</settlement>
     <country key="IT">Italie</country>
  </placeName>
 </birth>

And use a similar Chinese example from the same period from one of my projects, slightly modified for comparison: This guy in case you're curious

<death when="-0048-01-10">
  黃龍一年十日
  <placeName>
     <settlement type="city">長安</settlement>
     <country key="CN">西漢</country>
  </placeName>
 </death>

@calendar allows an editor to extract the date string from the document and turn it into something sensible.

<death when="-0048-01-10" when-costum="7R-1Y-10D" calendar="#chinReign" datingMethod="#chinTrad" period="#D29-E10">
  黃龍一年十日
  <placeName>
     <settlement type="city">長安</settlement>
     <country key="CN">西漢</country>
  </placeName>
 </death>

The point is that @datingMethod and @calendar are not the same. Also note the missing date element.

In the above encoding I use @datingMethod to describe the underlying lunar based calendar that goes in cycles (gengzi), which are shared across China at the time. The thing you find in the text, is the reign date, which is specific to each emperor, and in times of multiple competing dynasties there are separate reigns. The start of a reing does not have to fall on the 1st day of the first month of the year either.

I don't have strong feelings about which one should go into which attribute, my point is they both serve a purpose. And that allowing @calendar on things other then <date> does not strike me as arbitrary as the discussion so far makes it out to be. But i have a strong sense that many of the not-date elements, in the above list, can contain date-like strings, which might require a @calendar attribute if the date is sufficiently non biblical.

Now i think we can do better e.g. demanding that when @calendar appears one of the @when-costum variants could make sense. Or we could mandate <date> elements (which would invalidate the Guidelines example) , or .. i ll leave that to Part2. No point in going any further if y'all don't see the problem that i m seeing.

[martindholmes]

Just to clarify: your dates have been converted to proleptic Gregorian already, right? Hence the use of @when.

[duncdrum]

Just to clarify: your dates have been converted to proleptic Gregorian already, right? Hence the use of @when.

Yes @when normalized relative to xml version. @when-custom the reason we need @calendar in the first place.

[martindholmes]

@duncdrum If this is the date: 黃龍一年十日 Why not just wrap it in a date element?

[duncdrum]

@martindholmes because I don’t have to, it’s an adaptation of @sydb example from the guidelines.

birth does not demand date, so it taking @calendar makes sense, unless a whole bunch of rules get changed.

I switched birth for death because historical accuracy.

[martindholmes]

@duncdrum But when you use @calendar on <death>, you're implying that it applies also to the other content in there, aren't you? You're saying that it applies also to the city and the country. I think that's just sloppy markup, to be honest.

[sydb]

Yes @when normalized relative to xml version. @when-custom the reason we need @calendar in the first place.

No, @dating-method is how you indicate the <calendar> that applies to @when-custom.

[martindholmes]

Let's try to clarify again:

@when means (proleptic) Gregorian. No problem. @when-custom tells us what the date is according to the <calendar> pointed to by @datingMethod. @calendar tells us the <calendar> which applies to the following textual content:

黃龍一年十日 長安 西漢

Part of this content is a date, but some of it is the name of a city and some is the name of a country. Unless cities and countries are dependent on calendrical systems, this is just wrong. I think it should be this:

<death>
  <date when="-0048-01-10" when-custom="7R-1Y-10D" calendar="#chinReign" datingMethod="#chinTrad" period="#D29-E10">
    黃龍一年十日
 </date>  
 <placeName>
     <settlement type="city">長安</settlement>
     <country key="CN">西漢</country>
  </placeName>
 </death>

<death> has dating attributes because it's often used simply to wrap a date and nothing else; but when it's wrapping more than a date, I think you need to split out the date component, just as you split out the location information, to avoid ambiguity and confusion.

[duncdrum]

But when you use @calendar on <death>, you're implying that it applies also to the other content in there, aren't you? You're saying that it applies also to the city and the country. I think that's just sloppy markup, to be honest.

The point is that this sloppy markup comes from the Guidelines, i have simply replaced a person from one cultural context, with that from another.

<birth when="-0044-03-20">
  20 March 43 BC
  <placeName>
     <settlement type="city">Sulmona</settlement>
     <country key="IT">Italie</country>
  </placeName>
 </birth>

@when-customapplies as much to 長安 西漢as does @when to Sulmona Italie in the example above.

No, @dating-method is how you indicate the that applies to @when-custom. I d say the guidelines are unclear on that point, especially on the combination of @period and @calendar. However, we need to recognize the fact that both might be necessary to deal with sufficiently non-biblical dates.

in my example when-custom="7R-1Y-10D" is the 10th day, of the 1st year of the 7th reign period aka 黃龍一年十日. This is the cultural calendar as it appears in sources, the astronomical calendar about how many days in a year, how long these are, etc is in the @period . All normalized, with linked data in the <CalendarDesc> should it be the other way around, maybe, the point is neither the guidelines prose, nor the validation are making that obvious. Which does not scream corrigible error to my ears, but I said that already.

So far all i can say is that:

@calendar= should not be in att.datable,

unless there are more wide ranging changes to how tei deals with dates. The solution is not to get rid of @calendar on elements like <birth> but to make these assumption more explicit by means of validation. So they apply to @when and @when-custom alike.

On a further note, i have not yet whipped out the examples of <orgName> or other elements, that are specific to a date, a new reign is started because of an earthquake, and so a ministry gets renamed. In the current schema this can be expressed with @calendar on <orgName> which is good imv. Simply removing @calendar from att.datable will break this, while leaving @when available. However in the case of some of my sources, knowing the proleptical Gregorian data of a renaming of an institution is not as useful as knowing the dynasty and reign in which a title, post, placeName, … was actually used. So in a sense 西漢 is indeed a calendar sensitive way of saying China its the posthumous name of the dynasty.

[sydb]

Why not just wrap it in a date element?

because I don’t have to

I would argue you don’t have to use <date> unless you want to use @calendar, and then you do (or should) have to.

But you’re point about the "Ovi01" examples in the Guidelines being sloppy markup is well taken. But I still do not see why, just because a simple case can be handled sloppily, it is a good idea to spread that sloppiness around, as it were.

That is, having <birth> and <death> in att.datable at all is to allow the (extremely commonly desired) shortcut of

<birth when="2020-11-25"/>

rather than

<birth><date when="2020-11-25"/></birth>

But is it a good idea to extend that case?

[duncdrum]

Ok sounds like we're moving to

Part 2: what to do about it

• Opt 1: nothing. It is what it is because changes will be a break-in 🎶
• Opt 2: something, because Council clearly sees a problem.

From what i can gather there are three sets of questions:

• one about the wisdom of att.datable in its current form:
  • do we want to keep att.datable attributes on anything other then <date> if so which and why My main concern is that folks dealing with documents without proleptic Gregorian dates have equal opportunity access to sloppy syntactical sweetness. Beyond that I would be ok with making <date> mandatory.
  • should the presence of att.datable require a <date> child element, which kind of negates the need for it on e.g. <birth> s.a.
• one about the intended function and necessity of @calendar and @datingMethod and @period
  • do we need them all? I don't think dropping all is really on the table, but the Guidelines prose about how to use them could be improved 1 refers to the elements content 2 the attributes value, and 3 too meh
  • do we need both or just one? I think we need 2, but am happy to hear suggestions for how to get rid of more
  • should either or all be a member of att.datable As long as @when and @when-custom can occur in the same places, we need one pointer attribute to <calendarDesc> this seems largely a question about validation rules, and e.g. mandating one att.data.custom attribute. But as long as @when is normalized (proleptic Gregorian xml datatype) then it stands to reason that @datingMethod and @calendar can occur alongside it
• are dates that special that they warrant syntactic sugar for a unitDef again i lean towards yes

In a less radically invalidating mood, here are two concise forms that we should keep in mind:

<birth when="2020-11-25" calendar="#ROC">109-11-25</birth>

and

<birth when-custom="109-11-25" datingMethod="#ROC"/>

calendarDesc

[martindholmes]

@duncdrum Your two concise forms are doing two completely different things, of course.

The fact that your encoding is based on an example in the Guidelines isn't necessarily an argument in its favour, because this ticket is about changing the Guidelines because they don't seem quite right.

In all your examples, it appears (to me at least) that the distinction between @datingMethod and @calendar isn't absolutely clear. @calendar has nothing whatsoever to do with @datingMethod or any of the @custom-* attributes. It doesn't matter whether you have any custom- or non-custom dating attributes or not; @calendar is only about the text (from the original transcribed source) that appears in the content of the element. In all your examples, I believe you should be using a date element; all the stuff about the placeName components is I think a red herring, because it's the definition of those elements (presumably in a <place> somewhere) which should be the source of information about how they may or may not relate to, or be contingent on, a specific calendar or dating method. What you've concocted is ambiguous and confusing, and currently the Guidelines allow -- even encourage -- you to do that, but I don't think they should, and given that the solution to the ambiguities is trivial and involves a tiny bit of extra markup, I think you should reconsider how you encode these things. However, if you don't want to, then you can simply pin your ODD to an existing version of the Guidelines, and/or customize it as you see fit.

These are only my personal opinions, of course, not those of Council.

[duncdrum]

@martindholmes the thing is simply changing @calendar in isolation of other date related classes as the ticket here suggests, won't achieve the desired tightening of the Guidelines.

My point is that as long as

<birth when="2020-11-25"/>

is valid and good practice, Both

<birth when="2020-11-25" calendar="#ROC">109-11-25</birth>

and

<birth when-custom="109-11-25" datingMethod="#ROC"/>

are desirable applications of how these attributes function according to the Guidelines, in fact i have used such constructions so this is not just mythological encodings.

[martindholmes]

@duncdrum So it looks like the example encodings (other than these very simple examples) are in fact a red herring; you're not arguing that they're good encoding that should be encouraged, you're arguing something different.

One issue here is that <birth>, <floruit> and <death> are metadata elements; they only occur within person, personGrp and persona. The normal use of @calendar is to point to a calendar for the content of the host element, and my understanding has always been that the assumption would be that this text content is from a transcribed source. What you're saying is that this understanding is wrong; that a TEI encoder might create metadata elements in the header in which they want to write their own text content which relates to a specific calendar, and that calendar is different from the calendar they use for the processable custom dating attributes, and different again from the normalized Gregorian calendar they use in the regular dating attributes. But since this:

<birth when="2020-11-25" calendar="#ROC">109-11-25</birth>

is no different from this:

<birth when="2020-11-25" datingMethod="#ROC" when-custom="109-11-25"/>

I see no reason for the former at all. This is metadata that's under your control; you're not transcribing a text in these elements. The only exception would be if you want to add a third calendar which is different from the Gregorian and the ROC, but that can be achieved with a nested date anyway.

[duncdrum]

and my understanding has always been that the assumption would be that this text content is from a transcribed source.

The point i m failing to communicate is that if transcribe a Taiwanese document today (e.g.: publication date of an article in <bibl>), the date will be in #ROC:

<date calendar="#ROC">109-11-25</date>

Same if transcribe historical records (contracts, throne edicts, 16th century imprimaturs) the dates will be #chinTrad. Hence the presence of @calendar in att.datable. It being there is far from a corrigible error. <death>, <birth> occur in such documents e.g. in the biography sections of standard histories in the same pseudo-prose like fashion as the current guideline examples. So this makes sense:

<death when="-0048-01-10" when-costum="7R-1Y-10D" calendar="#chinReign" datingMethod="#chinTrad" period="#D29-E10"> 黃龍一年十日</death>

TEI encoder might create metadata elements in the header in which they want to write their own text content which relates to a specific calendar, and that calendar is different from the calendar they use for the processable custom dating attributes, and different again from the normalized Gregorian calendar they use in the regular dating attributes

Yes that too, for collections of documents, or documents with mixed calendar, a normalizations layer other than proleptic Gregorian make sense, and are useful.

Above all i argue against letting one set of documents get away with (clearly not transcribed, but provided)

<birth when="2020-11-25"/>

while not allowing the parallel structure for non-gregorian calendars. either:

<birth when-custom="109-11-25" datingMethod="#ROC"/>

or

<birth calendar="#ROC">109-11-25</birth>

[martindholmes]

I don't think anyone is arguing that this should be wrong:

<birth when-custom="109-11-25" datingMethod="#ROC"/>

Unless I misunderstand @sydb. But I do think this is strange:

<birth calendar="#ROC">109-11-25</birth>

because of my assumption that @calendar is intended for transcribed text, not metadata.

[duncdrum]

think of a birth-certificate.

@calendar is about

the date represented by the content of this element

irrespective of transcription or meta-data. neither of which hinges on membership with att.datable

109-11-25 when processed by NER will correctly be tagged as <DATE> so will 黃龍一年十日 it's not like ppl don't open novels by saying on such and such a day ...

[duncdrum]

part 3 to sum up

there are problems with att.datable and there are problems with the triplet of @calendar @datingMethod and @period. Neither of which is resolved by removing @calendar from att.datable that's the red herring solution imv.

I do not see the class membership as an error in the first place. Certainly as something requiring deprecation.

What council wants to do about the problems, if anything, is up to council.

[martindholmes]

But a birth certificate is a document that would be transcribed in the text or sourceDoc element; it's not a piece of metadata appearing in the header or in the linked data container. So it wouldn't have <person> in it, and therefore it wouldn't have <birth> in it.

[duncdrum]

Looking at @sydb list of elements, these can and do occur outside of the header in the text section, the Guidelines even show pseudo-prose for the contents of<birth>. If it's ok to use <orgName> inside <body> and it is in att.datable then @calendar needs to be in att.datable. If <birth> appears in the header with prose contents, and it can have @when it also needs @calendar.

[martindholmes]

<birth> etc. can only occur as in person, personGrp and persona. Those are metadata elements. persName, orgName and so on are not metadata elements, and they may occur anywhere in transcribed text as well as in header elements. Any element needing @calendar would get it by means of another class after it's removed from att.datable (if that's what ends up happening). The only question is where it makes sense to have @calendar; the mechanics are straightforward. I think @calendar should be more clearly and specifically defined to say that it relates to transcribed source text, and that it doesn't belong on those pure-metadata elements. But I don't think I'll ever convince you, so I'll retire at this point. :-)

[duncdrum]

@martindholmes i can totally be convinced that this is a good idea, as part of more wide ranging changes about dates that increase consistency, adjust validation scenarios, and modify the guidelines prose and examples.

Since this discussion started with status green, no deprecation necessary, I went by what’s in this ticket. I’m so far against the removal, but it’s not my call. But I think I stated my case, up to council what to do with it.

As always thanks for the constructive discussion.

[sydb]

Herein I will use @when as a stand-in for the attributes in att.datable.w3c and att.datable.iso, and “date” to mean “date, time, duration” or other temporal expression usefully normalized.

I think one way to look at this is that @when says “this thing happened at or represents a specific date, and here is the normalization of that date”. They do not say “there might be a date buried somewhere in my content, here is the normalization of that date”. Whereas @calendar is not about the date on which something (like acquisition of a manuscript) happened, but rather about which <calendar> should be used to interpret the transcribed content that represents a date.

I think it is unusual, but quite reasonable, to want to do both. I.e., to say “this object was acquired on stardate 4570.8”. But it seems to me important enough to avoid the “@calendar is about @when” confusion that it does not bother me to insist that the stardate be transcribed inside a <date> inside the <acquisiton> just so it can have an @calendar. Besides, I do not like the idea that in

       <acquisition when="2327-07-28" calendar="#stardate">
         A gift from <persName>Maurice Picard</persName>
         to his daughter-in-law <persName>Marie Picard</persName>
         in 4570.8, in celebration of her son’s birth.
       </acquisition>

the phrases “A gift from” and “her son’s birth” are in a calendar, or subject to different interpretations based on a calendar. I would much prefer to see

       <acquisition when="2327-07-28">
         A gift from <persName>Maurice Picard</persName>
         to his daughter-in-law <persName>Marie Picard</persName>
         in <date calendar="#stardate">4570.8</date>, in celebration of
         her son’s birth.
       </acquisition>

Am I being crazy? (Has been known to happen.)

[martindholmes]

@sydb I agree 100%. I think a date element should be used to clarify that the @calendar applies only to a string of text that is explicitly a date. I'm completely unconvinced by the idea that calendars apply in some weird way to other things such as locations; and even if there's an argument that they do, they don't apply in the same way as they do to a date, so the explanation of that relationship belongs somewhere else (in the place element itself, I think).

[duncdrum]

Am I being crazy? (Has been known to happen.)

Nope, but omitting an answer why a) mandating the following doesn’t follow from restricting @calendar to appear on <date>

        <acquisition>
          A gift from <persName>Maurice Picard</persName>
          to his daughter-in-law <persName>Marie Picard</persName>
          in <date when="2327-07-28" calendar="#stardate">4570.8</date>, in celebration of
          her son’s birth.
        </acquisition>

And b) how to preserve the editors freedom to go easy on attributes, and have something like this available

<acquisition calendar=‘#stardate’>4570.8</acquisition> 

Stardates, reign dates, lunar dates etc. are normalized via the calendarDesc, they're just not closely following the proleptic Gregorian xs:date format that is baked into xml. I m still non the wiser about @period shouldn’t that also have the same restrictions as @calendar?

@when says “this thing happened at or represents a specific date, and here is the normalization of that date”. They do not say “there might be a date buried somewhere in my content, here is the normalization of that date”.

I'd say that's a reinterpretation of the data-model, the model as it is now does not say that. In fact you can read the birth examples sans date to say exactly the opposite. If you want the model to say that, we need to address more then just @calendar class membership in att.datable

[duncdrum]

btw @martindholmes it just occurred to me that we are using transcribed to mean different things, i think you restrict it to what appears inside <tei:body> where as i also call something transcribed if it appears in the head (metadata) but it sticks to the appearance on the original document.

So in this context, i would use

<acquisition calendar=‘#stardate’>4570.8</acquisition> 

to transcribe a document which has a Seal or stamp on which the string 4570.8 indicates a the stardate. I honestly don't care where in the TEI document the transcription ends up, but I always aim to use element contents for transcription, and reserve attribute values for editorial additions.

I.E. I ve probably been doing it wrong for all those years 🤯

[martindholmes]

That's exactly right.

[duncdrum]

Hah at least we got that sorted! I ll drop the term, but will gladly continue the practice, which doesn’t strike me as that wild an approach 👺

PS: to be clear there would always also be a proper transcription in the body.

[martindholmes]

This is basically why we believe that @calendar is fundamentally different from the other dating attributes and belongs in its own class; it's saying something about original transcribed text. The only way I'd use it in a metadata element would be if that element contained a quotation from the source, and the quotation contained a date.