<t> element (and others) was (Re: XHTML <time> element proposal)

On 11/2/03 6:01 AM, "Karl Dubost" <karl@w3.org> wrote:

> Per se
> <time> is less readable than <temps> for a french
> <time> is less readable than <??> for a chinese.

No argument from me about that -- see other thread.

However, your statement does inspire me to shorten the element name even
more.

Instead of <time> why not use <t>?

This has the advantage of being more "readable" across the languages that
have words that mean "time" that start with a "t" and following the well
established convention from physics for using 't' as a variable and word to
mean 'time'.

Thus updated:

 <t>[ISO8601 datetime]</t>

e.g.

 <t>2003-10-29T15:00-08:00</t>
 <t>P1D</t>



On 10/29/03 6:54 PM, "Christoph Päper" <christoph.paeper@tu-clausthal.de>
wrote:

>> Similarly, I have encountered instances where a frequency element would
>> have been quite useful.  Something like:
>> 
>>  <freq>88.5mHz</freq>
> 
> IMO a generic method to combine value and unit is much preferable, like
> <data><val>88.5</val> <unit>mHz</unit></data>.
> 
> A year ago I proposed a single element to do it all in one:
> <http://lists.w3.org/Archives/Public/www-html/2002Nov/0110.html>
> I'm rather convinced today that that's not the best way to do it, but still
> believe there should be one.

I think I agree with the conceptual merit of your proposal for <nr>.

Though I'm not certain whether it is better to have one element <nr> or a
small number of elements for ordinals/generic/percentage, currency, time,
e.g.

 <num> (or <n>) - ordinal or generic numeric value. Percentages are simply a
stylistic convention of a generic value, e.g. <n>.1</n> perhaps could be
styled and presented (through some as yet to be invented CSS mechanism) as
10%.

 <money> (or <m>) - ISO 4217 monetary amount, e.g. <m>$10USD</m>

 <time> (or <t>) - ISO 8601 date, time, span.  see above.


I think these would be the most commonly used on the Web.

Phone numbers are already representable with the standard "tel:" or "fax:"
protocols.  Zip codes are probably better handled as part of an address
related standard like vCard.

For most of the rest in your proposal, it may be better to introduce a
simple Physics Module, e.g. for other physical quantities / SI units[2]
(distance, area, volume, mass, energy, temperature, frequency) as needed.
While such markup would be useful, I don't think any of those would be as
commonly used as <num>, <money> or <time> (<n>, <m>, <t>), at least in the
virtual world of the Web.

This kind of picking a small/useful/generic subset vs. fully representing
possibilities is also part of HTML philosophy (AFAIK) in contrast to other
more thorough formats like DocBook.


>> In any case, rather than waiting to add such new elements to XHTML 2.0, why
>> not simply create your own XHTML Modularization module[1] for them and
> 
> Yes, why not, but you should be sure about the best or at least a good way to
> do it before even starting to write such a module.

Agreed.  But one way of discussing ways to do it is for individuals to
propose such XHTML Modularization modules themselves.

Tantek

[1]
  http://www.w3.org/TR/xhtml-modularization/abstraction.html#sec_4.4.1.

[2]
 http://scienceworld.wolfram.com/physics/SI.html

Received on Sunday, 2 November 2003 14:36:20 UTC