Hi Scott,
Do you have any examples of the non-Gregorian dates being published
online? Or any examples of applications that can take non-Gregorian
dates as input?
I've got some Japanese folks looking into that.
I don't speak Japanese, but last week I was in a very popular Japanese
:
-
From: Scott Reynen [EMAIL PROTECTED]
Date: Tue, 15 Jul 2008 08:19:38 -0600
To: microformats-discuss@microformats.org
Subject: Re: [uf-discuss] Human and machine readable data format
On [Jul 15], at [ Jul 15] 5:51 , Ciaran McNulty wrote:
Another example of non-Gregorian calendaring is Saudi Arabia
Another example of non-Gregorian calendaring is Saudi Arabia, where
the arabic calendar is in common usage:
http://www.sama.gov.sa/
(actually clicking the 'english' tab on that page shows the gregorian dates)
-Ciaran McNulty
On Tue, Jul 15, 2008 at 3:40 AM, Karl Dubost [EMAIL PROTECTED] wrote:
On [Jul 15], at [ Jul 15] 5:51 , Ciaran McNulty wrote:
Another example of non-Gregorian calendaring is Saudi Arabia, where
the arabic calendar is in common usage:
http://www.sama.gov.sa/
Thanks Karl and Ciaran. I've added these examples to the wiki here:
On Sat, Jul 12, 2008 at 7:39 PM, Zachary Carter [EMAIL PROTECTED] wrote:
+1 for class=data-
Hidden metadata isn't going away anytime soon. HTML 5 features it,
RDF/RDFa uses it, the empty abbr pattern already does it, and many
others.
I think consensus seems to be that hidden data is ok for
Hello
On 12/7/08 14:50, Breton Slivka [EMAIL PROTECTED] wrote:
On Fri, Jul 11, 2008 at 6:47 PM, Dan Brickley [EMAIL PROTECTED] wrote:
Toby A Inkster wrote:
Paul Wilkins wrote:
We should leverage the computers ability to do the hard work for us.
pDate span class=dateFriday, July the
Not sure if this thread is only covering datetimes in abbreviations. The
title seems to suggest that it's more general so thought I'd chip in with a
thought on geo as an example. How would a parser deal with natural
(non_English) language here? Would it be expected to be able to parse
Seems to me there are 2 solutions:
1. relax the data hiding constraint (tricky because it's fundamental to the
uf design philosophy and it's relaxation has been rejected many times)
2. maintain the status quo. Keep the abbreviation design pattern for machine
friendly data and leave it up to
On [Jul 14], at [ Jul 14] 6:39 , Breton Slivka wrote:
To someone with a different calendar, ISO8601 may make just
as much sense as July 1st, 2007. that is: very little.
I'm assuming by different calendar, you mean non-Gregorian? If so,
what are the use cases for non-Gregorian dates in
On Tue, Jul 15, 2008 at 12:36 AM, Michael [EMAIL PROTECTED] wrote:
Seems to me there are 2 solutions:
1. relax the data hiding constraint (tricky because it's fundamental to
the
uf design philosophy and it's relaxation has been rejected many times)
2. maintain the status quo. Keep the
Scott,
But I have no idea what the use cases are for non-Gregorian dates
Are there many applications that can use such dates? The use cases
are crucial for evaluating whether hCalendar should support non-
Gregorian dates, and if so, how that should work.
I recently learnt that in Japan
See below.
Hope this helps,
Charles Belov
SFMTA Webmaster
--
Message: 4
Date: Tue, 15 Jul 2008 00:36:07 +1000
From: Michael [EMAIL PROTECTED]
Subject: Re: [uf-discuss] Human and machine readable data format
To: Microformats Discuss microformats-discuss
On [Jul 14], at [ Jul 14] 5:57 , John Allsopp wrote:
I recently learnt that in Japan there are two year numbering
systems. The western style one is more common, but it far from
uncommon to use the traditional Japanese year numbering system as
well.
Do you have any examples of the
Le 15 juil. 2008 à 11:16, Scott Reynen a écrit :
Do you have any examples of the non-Gregorian dates being published
online? Or any examples of applications that can take non-Gregorian
dates as input?
For those who need to understand.
http://en.wikipedia.org/wiki/Japanese_era_name
The
Another example of a form with Japanese Era Calendar
http://urakoma.com/bbs.html
following the character 年 there is a drop down menu where you can
choose an era or the gregorian calendar.
option value=1明治/option
option value=2大正/option
option value=3 selected昭和/option
option
Do you have any examples of the non-Gregorian dates being published online?
Or any examples of applications that can take non-Gregorian dates as input?
I think we've established non-Gregorian calendars exist, but most countries
officially adopted the Gregorian calendar several decades before
On Tue, Jul 15, 2008 at 12:53 PM, Breton Slivka [EMAIL PROTECTED] wrote:
Do you have any examples of the non-Gregorian dates being published online?
Or any examples of applications that can take non-Gregorian dates as input?
I think we've established non-Gregorian calendars exist, but most
On 14 Jul 2008 at 21:54, Toby A Inkster wrote:
So there will be cases where people want to publish non-Gregorian
dates, but for interoperability with iCalendar, they'll need to
include a machine-readable Gregorian equivalent date.
Actually, not necessary. The iCalendar spec [1] contains a
On 14 Jul 2008 at 22:39, Breton Slivka wrote:
There is another solution that I have been trying to advocate, which
is not metadata, and it's not natural language parsing. It is quite
simply, to define a strict date format that IS human readable,
But there already IS a strict date format, and
On Fri, Jul 11, 2008 at 6:47 PM, Dan Brickley [EMAIL PROTECTED] wrote:
Toby A Inkster wrote:
Paul Wilkins wrote:
We should leverage the computers ability to do the hard work for us.
pDate span class=dateFriday, July the 11th 2008/span/p
As I've said before, although my parser does support
The premise that publishers will pick any old format is merely an
assertion with no evidence. Please show us an example somewhere else
where this has happened, or perhaps a better argument than merely
insisting on the obvious truth of it.
The way I see it, if they publish in the wrong
+1 for class=data-
Hidden metadata isn't going away anytime soon. HTML 5 features it,
RDF/RDFa uses it, the empty abbr pattern already does it, and many
others.
Best,
Zach Carter
On Sat, Jul 12, 2008 at 1:23 PM, Jason Karns [EMAIL PROTECTED] wrote:
The premise that publishers will pick any
On Sat, Jul 12, 2008 at 2:44 AM, Ameer Dawood [EMAIL PROTECTED] wrote:
Just one more thing to add. Microformats should be designed in such a
way that authors are not obliqued to wrrite up a spcific date format
for display to users. If we are to follow the idea of a
machine-readable as well as
On Sat, Jul 12, 2008 at 9:47 PM, Paul Wilkins [EMAIL PROTECTED] wrote:
With the current system authors are obliged to write up a specific
date format for computers to parse, as well as one for humans to read.
They should not have to produce both types on every occasion.
If a parser isn't able
Toby A Inkster wrote:
Paul Wilkins wrote:
We should leverage the computers ability to do the hard work for us.
pDate span class=dateFriday, July the 11th 2008/span/p
As I've said before, although my parser does support dates in this
format, I strongly recommend *not* allowing these per
Hi,
Just one more thing to add. Microformats should be designed in such a
way that authors are not obliqued to wrrite up a spcific date format
for display to users. If we are to follow the idea of a
machine-readable as well as human-readable date format, then authors
would be obliqued to use that
Hello Ben
On Tue, 2008-07-01 at 17:42 +0100, Ben Ward wrote:
At the core, in breaking with the semantics of an HTML element,
we've
broken the behaviour of technologies using the element correctly and
intelligently (hence my strong opposition to continuing to stretch
ABBR outside of
On Fri, Jul 11, 2008 at 12:26 PM, Martin McEvoy
[EMAIL PROTECTED] wrote:
div class=item updated
pDate span class=value 2008-07-11T00:01+0100Friday, July the
11th 2008/span/p
/div
We should leverage the computers ability to do the hard work for us.
pDate span class=dateFriday, July
Paul,
we should leverage the computers ability to do the hard work for us.
pDate span class=dateFriday, July the 11th 2008/span/p
The date can be easily parsed by the system, in a number of limited
formats at first but growing in capabilities over time.
that date can be easily parsed. But
On 3 Jul 2008 at 10:03, Scott Reynen wrote:
On [Jul 2], at [ Jul 2] 4:37 , Bob Jonkman wrote:
In an appointment, the date IS the content.
*A* date is, but not the ISO date. I think that's a subtle but
important distinction we've overlooked too often. You never see ISO
dates
On 3 Jul 2008 at 9:54, Guillaume Lebleu wrote:
Bob, assuming that screen readers only read out the content of abbr's
@title, this solution looks promising (I've tried with VoiceOver, but
the title content is ignored.)
The only problem of course is for human content authors who are
Breton Slivka wrote:
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
On Thu, Jul 3, 2008 at 7:04 PM, Dan Brickley [EMAIL PROTECTED] wrote:
Breton Slivka wrote:
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
On Thu, Jul 3, 2008 at 8:39 AM, Breton Slivka [EMAIL PROTECTED] wrote:
On Thu, Jul 3, 2008 at 7:04 PM, Dan Brickley [EMAIL PROTECTED] wrote:
Breton Slivka wrote:
I offer the challenge to those developers: If you sincerely believe
that simple internationalized date parsing is an unsolvable or
On [Jul 2], at [ Jul 2] 4:37 , Bob Jonkman wrote:
The difference with ISO dates is we've previously defined them as
content; I'm suggesting that's a mistaken definition, as these dates
don't function as content in our reference standard iCalendar.
I disagree. In an appointment, the date IS
1 Jul 2008 6:28 Scott Reynen microformats-
[EMAIL PROTECTED]
The difference with ISO dates is we've previously defined them as
content; I'm suggesting that's a mistaken definition, as these dates
don't function as content in our reference standard iCalendar.
I disagree. In an
Le 3 juil. 2008 à 01:36, Guillaume Lebleu a écrit :
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,
[…]
Do you still see this as dangerous practice?
not dangerous but unpractical in the case
I honestly believe the bloat to
parsers would be significant
sorry, I meant I Honestly believe the 'bloat' to parsers would _not_
be significant
___
microformats-discuss mailing list
microformats-discuss@microformats.org
As the exchange between Ben and Jeremy has shown what is human readable
is up for debate. Having spent far too much time looking at the ISO date
formats they are all readable to me, but I know that's not the case for
everyone else.
We need to expand the discussion and ask those involved in the
On [Jun 30], at [ Jun 30] 11:12 , Breton Slivka wrote:
I think you'll find that metadata of any kind is a comprimise of the
microformats core principles
What I mean by metadata is information about content, which already
makes up the bulk of microformats, e.g. class names, rel values, tag
On 1 Jul 2008, at 13:28, Scott Reynen wrote:
The difference with ISO dates is we've previously defined them as
content; I'm suggesting that's a mistaken definition, as these dates
don't function as content in our reference standard iCalendar.
In my view, it's not so much that an ISO dates
Glenn Jones wrote:
As the exchange between Ben and Jeremy has shown what is human readable
is up for debate. Having spent far too much time looking at the ISO date
formats they are all readable to me, but I know that's not the case for
everyone else.
We need to expand the discussion and ask
On 1 Jul 2008, at 17:01, Guillaume Lebleu wrote:
Since the BBC's request was specifically related to screen readers,
we may want to distinguish machine-readable, human-readable and
human-hearable. I think there is less debate re: what is human-
hearable than there is debate re: what is
On Mon, 2008-06-30 at 07:57 +0100, Glenn Jones wrote:
abbr class=dtstart title=Date: 25 January 2008 at 15:30, Time zone
+1:00Jan 25 08/abbr
My thought for some time now is that the problem should be simplified a
little, maybe also the problem could be looked at a little differently
by trying
Against this we have statements like Tantek's. I'm vehemently opposed
to putting data in the class attribute. We must find better
alternatives. We must not go down the path of invisible (dark)
(meta)data - IMHO that principle is inviolable for microformats.
I respect Tantek's views and I
Martin McEvoy wrote:
My thought for some time now is that the problem should be
simplified a
little, maybe also the problem could be looked at a little differently
by trying to mark up datetime as all one thing which is great for a
machine, when really you should be trying to mark it up in a
On 30 Jun 2008, at 16:16, Jeremy Keith wrote:
Now I'm not saying that this solution is perfect but it's by far the
best I've seen so far. It doesn't involve hiding data and it doesn't
involve stuffing data values in the class attribute. It *does* still
use the abbr element for a usage
On Mon, 2008-06-30 at 16:16 +0100, Jeremy Keith wrote:
span class=dtstart
On abbr class=value title=2008-06-30June 30th/abbr
at abbr class=value title=09:009.00am/abbr
/span
Yes Jeremy I like this idea but...
its this bit I am having difficulty with
[...]
On abbr class=value
Ben Ward wrote:
I disagree with this. I don't think it's acceptable for us to define
microformats that break with the specified semantics of HTML. Yes,
it's frustrating that HTML is spec'd the way it is, but the intent
of the HTML title attribute is to be for human data. The intent of
the
Martin McEvoy wrote:
semantically on their own the above does not mean much nothing at all
really, search engines, parsers, things that index dates and times,
would have to peek at the parent to find out what the actual values
are
for.
But that's true already of any instance of the value
On [Jun 30], at [ Jun 30] 11:11 , Jeremy Keith wrote:
I disagree. I think that writing:
abbr title=14:005 minutes ago/abbr
...clarifies the abbreviated form.
I think the problem may be clarified by actually writing those out in
a sentence:
I arrived at work 5 minutes ago.
I arrived at
Scott wrote:
I think the problem may be clarified by actually writing those out
in a sentence:
I arrived at work 5 minutes ago.
I arrived at work 14:00.
The latter doesn't seem human-readable to me.
But it does to me. And that's kind of the crux of the issue. Defining
human readable is a
On [Jun 30], at [ Jun 30] 4:29 , Jeremy Keith wrote:
There are a few cases where we are specifying content syntax for
publishers, e.g. phone type in hCard. And these are all similarly
problematic. I think we might get closer to solving these problems
by considering them not in terms of
Le 1 juil. 2008 à 12:50, Scott Reynen a écrit :
If HTML offered us a @metadata attribute, I think we'd do something
like this:
abbr title=June 30th, 2008 metadata=2008-06-306/30/08/abbr
* HTML 5
time datetime=2006-09-23
title=June 30th, 20086/30/08/time
* RDFa
span
I think approaching ISO dates as metadata rather than content will remove
the need to compromise on core principles.
I think you'll find that metadata of any kind is a comprimise of the
microformats core principles. It's information hiding, and the
example that tantek uses is the meta tag,
55 matches
Mail list logo
