LISTSERV mailing list manager LISTSERV 15.5

Help for HTML-WG Archives

HTML-WG Archives

HTML-WG Archives


Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font


Join or Leave HTML-WG
Reply | Post New Message
Search Archives

Subject: Re: Changes to i18n draft
From: "Terry Allen" <[log in to unmask]>
Reply-To:[log in to unmask]
Date:Tue, 5 Sep 95 18:02:49 EDT

text/plain (109 lines)

| 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."

| <blockquote>
| <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>
| ..
| </blockquote>

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...

Same question.

| > 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
|    author.

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
Current HTML 2.0 spec:

Back to: Top of Message | Previous Page | Main HTML-WG Page



CataList Email List Search Powered by the LISTSERV Email List Manager