| Terry Allen:
| > I really don't understand this example, which has been given several
| > times. In what context would one write <date
| > value="1995-09-05">today</date>, for what existing application, and
| > what would one expect one's reader to understand from it today, and
| > in the future? It seems tangential to the main discussion, for
| > which a straightforward example would be <date
| > value="1776-07-04">July 4, 1776</date>.
The following example doesn't have the temporal dependency of "today."
| <p>Listen, my children, and you shall hear
| <br>Of the <time value="0000 -0500">midnight</time> ride of Paul Revere
(inaccurate; local time in eastern Mass is over half an hour off that
of the time zone, and local time is all they had in Paul's day)
| <br>On the <date value="1775-04-18">eighteenth of April in seventy-five</date>
In what existing application would this be helpful?
| Or, simply for stylistic purposes:
| <h3>Be it resolved:</h3>
| <p>That this council, on <date value="1995-09-05">this, the fifth day
| of the ninth month of the one thousand, nine hundred, ninety-fifth
| year of Our Lord</date>, does hereby...
| > Re money values, which is authoritative, the att value or the
| > element content?
| I would expect that for all of these, the attribute should be used for
| any localization or indexing, but that if (and only if) it is absent,
| the content would be used. My reasons for this suggestion are that
| 1) Informational elements should have content whenever possible, so
| that older clients can display something.
so then the element content should be authoritative, no? Either way,
duping the information creates fertile ground for error and confusion.
I'm still searching for the *existing application* that is enabled
by this markup; we ought to examine it so as to be able to follow
out the implications of our design choices.
If, as I suspect, there isn't any, then we need do nothing yet.
| 2) The author should be able to control the default display, because
| even if we don't allow it, it *will* be done.
that can be done without any MONEY element at all
| 3) The minimum number of keystrokes should be required from the
consistent with other objectives; eliminating the duplication of info
certainly saves keystrokes!
| 1) and 2) require that arbitrary content be allowed, with the
| standardized information in the attribute, and 3) requires that the
| attribute be omissable if the content is in a standard form.
| <date>1995-09-05</date> and <date value="1995-09-05">today</date>
| should both be legal.
Now you're back to that temporal dependency ("today"). Let's fix
that example up and change "today" to "5 September 1995". Now I
see the choice as between "<date>1995-09-05</date>" and
"5 September 1995", that simple. If I want automatic processing
I use markup, if not, I don't. What existing application shows that
this is not the right design?
| If the first isn't, I (as author) am going to be irritated, and/or do
| <date value="1995-09-05"></date>, which will inconvenience older
| client users. Even if I do <date
| value="1995-09-05">1995-09-05</date>, it increases the possibility of
| a typo.
Yup. Real good reason not to duplicate info.
| If the second isn't, I'm not going to bother to tag non-standard
| dates, and information will be lost, and then Somebody will come along
| with a client that allows me to do it in some nonstandard way, and
| then where will we be?
No information is lost; it just isn't available for automatic processing
(maybe). It's the actual use of this info on the Web that we need to
look at as justification for doing anything at all in this area.
Terry Allen ([log in to unmask]) O'Reilly & Associates, Inc.
Editor, Digital Media Group 101 Morris St.
Sebastopol, Calif., 95472
A Davenport Group sponsor. For information on the Davenport
Group see ftp://ftp.ora.com/pub/davenport/README.html
Current HTML 2.0 spec: