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

[Dan O'Donnell]

On Thu, 2007-15-02 at 21:20 -0500, Syd Bauman wrote:

On this issue I must confess, I like D better than anything presented;
and think the namespace idea is sooper. We already use namespaced
attributes, of course, so could we do it?

-dan


> > That last one is tricky. 
> 
> Indeed it is.
> 
> 
> > I'm not sure, Syd and Sebastian, why you have characterised the
> > "attribute-level" solution (A) as NOT making the easy things easy,
> > and "just too confusing for day to day use". Could you clarify
> > where the confusion might lie please? It seems to me that we could
> > have <date value="2007">this year</date> and that this is easy. So
> > I must be missing something.
> 
> 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.
> 
> 
> > 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=.
> 
> 
> > 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. 
> 
> 
> > 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.
> 
> 
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- 
Daniel Paul O'Donnell, PhD
Chair, Text Encoding Initiative <http://www.tei-c.org/>
Director, Digital Medievalist Project <http://www.digitalmedievalist.org/>
Associate Professor and Chair of English
University of Lethbridge
Lethbridge AB T1K 3M4
Vox: +1 403 329 2378
Fax: +1 403 382-7191
Homepage: http://people.uleth.ca/~daniel.odonnell/