[tei-council] <date>, <distance>, and <measure>

Syd Bauman Syd_Bauman at Brown.edu
Fri Jan 19 23:19:30 EST 2007


Great minds think alike. (But are they right?)

I am in the midst of yanking out <day>, <year>, etc. from the
Guidelines. In doing so I re-worked several examples that use the
<distance> element. I found myself wondering if <distance>, which is
pretty much syntactic sugar for <measure unit="time">, should also be
ditched. Then I came across the following comment:

<!-- really dont want to keep distance : shd be same as measure -->

I don't think Michael ever used "shd", and I know I didn't, so I'm
giving Lou credit for this insight.


But perhaps this one is syntactic sugar sweet enough to keep. Here's
an example.

  <date>
    <distance dur="P07D">A week</distance>
    <offset>before</offset>
    <date type="occasion">the meeting</date>
  </date>

(Note that "P07D" is the ISO & W3C format for a period of seven
days.)

  <date>
    <measure commodity="time" unit="d" quantity="7">A week</measure>
    <offset>before</offset>
    <date type="occasion">the meeting</date>
  </date>

(Note that "d" is the symbol for "day" approved by CIPM for use with
SI units.)

<distance> is also used within <placeName> and <geogName> for the
same kind of thing, but it does not have the right attributes to
provide a regularized value. Thus I'm in favor of using <measure>
instead of <distance> for <placeName> and <geogName>.

If I had my druthers, I think I'd prefer to use dur= on <measure> in
alternation with the other three attributes:

element measure {
   (
     attribute dur { xsd:duration }?
     |
     (
       attribute unit { data.enumerated }?,
       attribute quantity { data.numeric }?,
       attribute commodity { data.words }?,
     )
   ),
   etc.
 }
 
At the moment I don't think ODD processors can handle that sort of
construct, so if we went this route we would probably want to enforce
it with a Schematron rule.
 




More information about the tei-council mailing list