TEIC / TEI

The Text Encoding Initiative Guidelines
https://www.tei-c.org
Other
279 stars 88 forks source link

Examples for @calendar and @datingMethod #1421

Closed schassan closed 8 years ago

schassan commented 8 years ago

Right now, the examples for @calendar use capitalised values but all lowercase for @datingMethod. (#Gregorian/#Julian vs. #gregorian/#julian). Is there a reason why or could this be harmonised, preferably to lowercase?

lb42 commented 8 years ago

There are (only) two cases where the lowercase version is used, both on @datingMethod in att.datable.custom; elsewhere (notably in the text of the Guidelines) the preferred form seems to be e.g. "#Julian_England". So, if anything, those two are the ones that should be changed.

martindholmes commented 8 years ago

As a general rule, lowercase/camelback is preferred, I think, so I would vote to change the upper-case ones. There's nothing wrong in principle with exemplifying a variety of practices for this sort of thing, but I agree that in this rather specialized and already a bit confusing context, it would be helpful if readers see clearly that @calendar and @datingMethod are likely to be pointing at the same <calendar> elements in most cases.

lb42 commented 8 years ago

The upper case usage is not one I would prefer myself, but since whoever added this material to P5 clearly did prefer it, and since consistency is to be prized above all, for the reasons Martin adduces, it's less work and less perurbation to go for uppercase consistently, methinks.

ebeshero commented 8 years ago

Dear all, This looks like the kind of perturbing task that might be handed to a newbie on Council, and I'd be happy to take it on, though I'd tend toward turning the values all lower case.

Elisa Typeset by hand on my iPad

On Jan 11, 2016, at 12:47 PM, Lou notifications@github.com wrote:

The upper case usage is not one I would prefer myself, but since whoever added this material to P5 clearly did prefer it, and since consistency is to be prized above all, for the reasons Martin adduces, it's less work and less perurbation to go for uppercase consistently, methinks.

— Reply to this email directly or view it on GitHub.

lb42 commented 8 years ago

Maybe we should ask whoever it was that created the value "Julian_England" why they did it like that before proceeding?

martindholmes commented 8 years ago

It was probably me, and I would either have done it thoughtlessly, or by analogy with an existing example in the Glines, or possibly because I took it from data in one of my own projects (although we use lower-case at this point, and have for a while).

ebeshero commented 8 years ago

I'm looking at our explanation of the two attributes, @calendar vs. @datingMethod on the Guidelines now, and the Note seems pertinent: "Note that the calendar attribute (unlike datingMethod defined in att.datable.custom) defines the calendar system of the date in the original material defined by the parent element, not the calendar to which the date is normalized."

Thinking about the distinction between the two, does this provide an argument for representing the values of @calendar or @datingMethod in different ways? For a second I thought maybe yes, but on sober reflection I think, really no. The same project might use @datingMethod and @calendar, and if that were my project I'd want to use the same values for each since they refer to standard systems of dating.

What gives me pause is the question of whether the value of the @datingMethod attribute points to a system of normalization--a method for recalculating dates, while the @calendar refers to something potentially fuzzier, the way the date was historically recorded following a system current in say 1655 that we possibly wouldn't use in our normalized rendering of dates in a project. Does the attribute value #gregorian mean the same system in historical documentation as it does in modern recalculation to plot in a Gregorian calendar?

If I'm making this way too complicated, please advise. I'm also happy to go ahead and just edit the examples on @calendar to make them lower case as we were discussing here--it would be my first "real" (serious and not just correcting-a-typo) edit in the Guidelines, though, and I want to make sure it's appropriate. (And I can certainly hold off on this until after the freeze on 3/15--Gregorian!--if that seems wise.)

martindholmes commented 8 years ago

Hi Elisa. @calendar and @datingMethod are both pointers that we'd expect usually to point to a <calendar> element somewhere. I don't think there's any reason (or really any practical method) to represent them in different ways; they're just pointers. In our MoEML project, which uses these attributes everywhere, we simply point to centralized <calendar> elements; the code which calculates equivalences and converts between calendars is external to this, although prose descriptions of the calendars should presumably explain how they relate to each other.

To answer your question: the attribute value "#gregorian" would normally point to something like this (with the exact description depending on the project context):

<calendar xml:id="gregorian">
          <p>The Gregorian calendar, used in the British Empire from September 1752. Sometimes
            referred to as <mentioned>New Style</mentioned> (NS). Years run from January 1 through December 31.</p>
</calendar>

Since the [proleptic] Gregorian calendar is the most reliable and software-supported calendar/dating method available to us (as far as I know, and excepting Star Dates of course :-)), I would expect it to function pretty much as a universal, but obviously if you did have variant forms of the Gregorian calendar, you would define them as separate <calendar> elements with different @xml:ids, and point to them separately where appropriate.

ebeshero commented 8 years ago

Thanks, Martin. Your example is kind of what I imagined of common usage. Really, I think we ought to make these referents uniform. Is there any objection here to our altering the example in the guidelines, then? I'd just change the values so they're uniformly lower case.

martindholmes commented 8 years ago

I think all the examples should be consistently in camel-case, and since I was (if I remember correctly) inadvertently responsible for the some of the upper-case ones, and I regret it, I don't think it'll be upsetting to anyone to change them in the interests of consistency.

lb42 commented 8 years ago

I think I have already changed the weird "Julian_England" ones into "#julian" or "#julianEngland"

ebeshero commented 8 years ago

Okay--so this one's done? Should we change the status...? (Sorry--I'm being quite the noobie here but just checking on tickets assigned to me--quite belatedly checking, too in the rush of the teaching semester.)

lb42 commented 8 years ago

probably should check the sources first

sydb commented 8 years ago

This is a "go" for @ebeshero to check remaining examples and regularize camelCase pointers.

ebeshero commented 8 years ago

found, regularized, and committed to dev.