And yet, to not do so means breaking another restriction. It's about
give and take. Is it better to make it easier for publishers, and
harder for parsers, or is it better to store the same date twice, and
let one go out of sync?
Another solution is to just store ISO dates free and clear, and offer
a javascript library to parse it into a variety of common/
international date formats. My basic point is, that it is impossible
to satisfy all the restrictions with one format. Perhaps it is better
to have several ways to mark it up, depending on the situation. Which
restriction is it important to NOT break for a particular situation?
On 04/05/2007, at 12:42 PM, Michael MD wrote:
I don't think this will work, for the same reason tel-type and
adr- type don't work: l10n/i18n. They require displayed machine
values to be in English.
<span class="vmonth" lang="en">July</span>
<span class="vmonth" lang="es">julio</span>
<span class="vmonth" lang="jp">7 月</span>
<span class="vmonth" lang="ru">июль</span>
good point ...
parsing it might end up needing a database of day and month names
and character sets and numbers in every known language!
(possibly also other types of calendars that might be used in some
parts of the world ... this could get very complicated very quickly!)
_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
