[tei-council] what to do with dating attributes -- VOTE!

[Conal Tuohy]

> With the attribute-level solution every time any user (who hasn't
> removed attributes in her customization) inserts a <date> element,
> her XML-aware editor would present here with a slew of possible
> attributes: 
>    value=
>    value.iso=
>    value.usr=
>    notBefore=
>    notBefore.iso=
>    notBefore.usr=
>    notAfter=
>    notAfter.iso=
>    notAfter.usr=
>    from=
>    from.iso=
>    from.usr=
>    to=
>    to.iso=
>    to.usr=
>    dur=
>    dur.iso=
>    dur.usr=
> not to mention the non-date-specific attributes. No simple check-box
> style customization could change this. (Although, as I'm fond of
> pointing out, it isn't really that hard without the check-box
> simplicity.) For the vast majority of users, 2/3 of the above
> attributes would never be used, and would just be in the way.

Would it not be simpler to make the "complex" attribute sets optional?
i.e. the the default TEI schemas would not include the complex dates,
and the user would have to explicitly add them, if they wanted them,
rather than remove them? Since most users would be fine with just
"simple" (W3) dates, for anything else it might be quite reasonable to
require a customization to explicitly add them.

> > I think B and C are weaker (if I understand them correctly) in that
> > they would prohibit mixing calendars in a document (at least, with
> > the same element, so that date/@value would have to have a
> > consistent type throughout a document). Is that a correct
> > understanding? 
> 
> Off the top of my head I think that is correct if the user is using
> the "simple format" date attributes, regardless of which option we
> choose. That's because the simple W3C format is definitionally
> Gregorian, and arguably proleptic Gregorian. Things are a little
> better with ISO 8601, which is explicitly Gregorian or proleptic
> Gregorian, and arguably the syntax could be used for others.
> I'm of a mind that, regardless of system, we should define value= and
> iso-value= as (proleptic) Gregorian. User-defined values could be of
> whatever calendar the user desired. The *content* is in whatever
> calendar is specified by calendar=.

Agreed. So if a user wanted to mix a Gregorian with a non-Gregorian
calendar in the same document (which seems to me quite reasonable), I
can see how they could do that with A and D, but how to do that with B
and C? 

If B (datatype level), then the mixed-calendar encoder would have to
select the "loose" data type for all dates (the "lowest common
denominator" data type), and they wouldn't get the benefit of
W3C-validation of any dates which genuinely were simple Gregorian dates.


If C (class level), then you suggested 2 options:

C(1): classes use different attribute names, hence can be mixed (from
the encoders' perspective this is the same as option A, just implemented
using classes); or
C(2): classes use the same attribute names, hence they can't be mixed
(from the encoders' perspective this is like option B)

> > In some ways I prefer D because it implies that the attributes have
> > particular semantics which are in a sense independent of the
> > particular calendrical "syntax" used.
> 
> I'm sorry, I think I'm too tired (or too stupid :-) to understand
> this. 

I just meant that it was an attractive idea to have date/@value rather
than date/@iso-value and date/@w3-value (or whatever), since a date, no
matter how you express it, is still just a date. 

> > Incidentally, ... use distinct XML namespaces for the different
> > data types. ... e.g. ... <date iso-8601:value="--0301">St David's
> > day</date> or ... <date i:value="--0301">St David's day</date>
> 
> Really interesting idea (that I never thought of) that yields a
> very nice syntactic result. But I don't think the implications --
> that these attributes somehow belong to some other markup language
> than TEI -- are acceptable.

I think that's a strange implication to take. cf @xml:lang and @xml:id
which are inarguably (I hope?!) part of the TEI markup language, despite
belonging to a distinct namespace. Remember, too, that all the other
"TEI" attributes are not in fact in any namespace. An XML markup
language is quite a different beast from an XML namespace. But hey, I'm
not fussed about the idea ... it was just a suggestion.

Con