[uf-discuss] Human and machine readable data format

[Breton Slivka]

This is not internationalization of metadata, this is
internationalization of Data, as in Content. We are talking about a
date format that will be read out to users not just in the US, but
potentially anywhere in the world. I honestly believe the "bloat" to
parsers would be significant. Particularly if our precious parser
authors are not incompetant, and we hope they are not. Please note
that many programs (Excel is one example off the top of my head)
provides exactly this type date parsing dependant on locale. Many more
programs and operating systems provide services for the generation of
Locale specific dates. The ecmascript standard includes such a
facility for both generation, and parsing of locale specific dates.
Ecmascript parsers must be light enough to work on a mobile device
with a browser.

I hope I have been persuasive in demonstrating that more sophisticated
parsers will be necessary if we are to satisfy the "No Information
Hiding" and "Humans First, Machines Second" principles of the
microformat community. I find it frustrating that we still have people
being sensitive about the bloat.

I offer the challenge to those developers: If you sincerely believe
that simple internationalized date parsing is an unsolvable or
difficult problem (which, as I have pointed out has been solved
numerous times already, with two examples), please present your
evidence. Why is avoiding this work more important than Accessibility?
Why is avoiding this work more important than avoiding hidden
metadata?





On Thu, Jul 3, 2008 at 6:04 AM, Ameer Dawood <ameer1234567890 at gmail.com> wrote:
> Hi G,
> Internationalization of metadata is a bad and ineffective concept. It would not only result bloat in pharsers, but also bloat in the data format itself. You are proposing to internationalize the machine readable date which is metadata (and not content, in this case). A very clear example would be; if we are to internationalize CSS then "border-color" would become "border-colour" in en-uk. It's like proposing this change with a lang attribute/element.
>
> Ameer
>
> _____________________________
> Sent from my phone using flurry - Get free mobile email and news at: http://www.flurry.com
>
> --- Original Message ---
> Date: Wed Jul 02 09:43:00 PDT 2008
> From: Guillaume Lebleu <guillaume at lebleu.org>
> To: Microformats Discuss <microformats-discuss at microformats.org>
> Subject: Re: [uf-discuss] Human and machine readable data format
> ---
>
> Michael MD wrote:
>> Allowing language conventions for date parsing to be determined by anything "global" sounds a bit dangerous to me.
>>
>> Someone might post on a shared blog/forum site in a different country and mark it up in a way that does not match a lang attribute somewhere else on the page!
>>
>> also - who is going to say that all replies to the post or comments that might also appear on that same page are going to follow the same language rules
> Sorry if I didn't express myself clearly. What I meant here was that a lang="..." attribute on the element of class vevent or dstart is recommended at all times (to deal with the very ambiguity you are referring to), but is optional to comply with DRY. If not present, its value may be inferred from the closest containing/ancestor element with a lang attribute, for instance a lang attribute value at the level of the html element.
>
> In other words, if I want to write my date in French in an en-us html document, I'd have to attach lang="fr" to my date or its containing content, but if I want to write my date in American English in the same document, I don't have to attach lang="en-us", although it wouldn't hurt to.
>
> Do you still see this as dangerous practice?
>
> G
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>