[tei-council] date attributes: summary, problems, and some suggestions

[Christian Wittern]

Sebastian Rahtz wrote:
> Syd Bauman wrote:
>>
>> Hmmm... how about att.normalizedDate?
>>   
> sure
fine

>>   
> IF (a big "if") we mandated the "yet-to-be-agreed-upon-let-alone-specified
> mechanism in the instance that points to the schema", I could
> sort of go along. But for TEI P5 1.0, I just don't see this
> work being completed and implemented by anyone.

I will go out on a limb here and suggest a "small" solution: In the 
wilderness of the XML universe, there exist already a number of ways to 
associate an instance with a non-DTD schema:

XSD uses schemaLocation
oXygen uses a pi "oxygen"
nxml uses a elaborated mechanism which somehow ends in processing a 
schemas.xml file
.. there will be others.

How about we just give the users a spot in the header to declare which 
one they are using ("xsd", "oxygen", "nxml", "you-name-it"), without 
actually implementing our own?  The only thing we will have to ponder is 
if we want to maintain a registry of values for this list -- I would say 
that might be the price we have to pay for this.

To me, this is one of the infrastructural issues we should not lightly 
postpone.

Now back to the topic,

>> One attribute, syntax of value determines what kind of date format:
>>   no prefix   = entire value is a simple format (i.e. W3C) date
>>   prefix 'i-' = remainder of value is an ISO 8601 date
>>   prefix 'x-' = remainder of value is a user-defined format date
>>
>> Thus:
>>
>>   <date value="2007-02-14"/>
>>   <date value="i-2007-W07-3"/>
>>   <date value="x-1385-11-25"/>   <!-- Persian calendar -->
>>   <date value="x-hebrew-5767-11-27"/>
>>   <date value="x-islamic-1428-01-27"/>   
> I would not actually blow up Parliament in protest
> if we adopted that, but I still don't like the idea
> of @value sometimes being valid with standard
> datatypes and sometimes not.

You will need to check for the type before blindly processing them. 
What I like is the self-declaring and on-the-spot expandable property of 
this proposal.

>> None of the user-created formats are ever going to have standard
>> software suite support, so I don't think we should fret much over
>> that.
> agreed. but at least lets isolate them in their own names.

Which will put a burden on you if you suddenly discover a new type of 
dates in your texts to go back to the schema-drawing-room called Roma 
for another round.

>>
>> So, IMHO, we are down to either class-level or all-in-one.   
> thats progress.

I'm with you here.

> as I read your message, you've more or less
> persuaded yourself to agree with my class
> proposal a la att.global?


Except that we still have the all-in-one proposal.  I might be biased 
since I
work more or less daily with xml:lang attributes, but that solution has 
the advantage
of being simpler technically.

Christian
-- 

  Christian Wittern
  Institute for Research in Humanities, Kyoto University
  47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN