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
busine
ssage:
-
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 Saud
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:
http://microformats.org/wiki/hcalend
Bob Jonkman wrote:
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 iCalenda
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 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, a
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
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, bu
> 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 be
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.
明治
大正
昭和
平成
西暦19
西暦20
--
Karl Dubost - W3C
http://www.w3.org/QA/
Be Strict To Be Cool
__
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 era
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 non-Gre
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: Micr
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
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
Scott Reynen wrote:
I'm assuming by "different calendar," you mean non-Gregorian? If so,
what are the use cases for non-Gregorian dates in hCalendar?
It's not so much the case of wanting to encode non-Gregorian dates in
hCalendar, but wanting to include non-Gregorian dates on the web page.
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
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 p
>
> 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
> M
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.
Date Friday, Jul
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
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'
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 wel
+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 a
Breton Slivka wrote:
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.
I have previously mentioned the
> 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
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.
>>> Date Friday, July the 11th 2008
>>
>> As I've said before, although my parser does support dates
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
Toby A Inkster wrote:
Paul Wilkins wrote:
We should leverage the computers ability to do the hard work for us.
Date Friday, July the 11th 2008
As I've said before, although my parser does support dates in this
format, I strongly recommend *not* allowing these per spec, as it will
lead to un
Paul Wilkins wrote:
We should leverage the computers ability to do the hard work for us.
Date Friday, July the 11th 2008
As I've said before, although my parser does support dates in this
format, I strongly recommend *not* allowing these per spec, as it
will lead to unpredictable and incon
Martin McEvoy wrote:
Date Friday, July the
11th 2008
There are a couple of problems with this:
Firstly, the class element may contain more than two classes - e.g.
it may contain some others that have been added for styling or
Javascript purposes. When there are more than two classes
Paul,
we should leverage the computers ability to do the hard work for us.
Date Friday, July the 11th 2008
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 what about "tomorrow",
On Fri, Jul 11, 2008 at 12:26 PM, Martin McEvoy
<[EMAIL PROTECTED]> wrote:
>
>Date Friday, July the
> 11th 2008
>
We should leverage the computers ability to do the hard work for us.
Date Friday, July the 11th 2008
The date can be easily parsed by the system, in a number of limited
f
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 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
>
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
Bob Jonkman wrote:
tomorrow
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 a
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 th
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
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 solve
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 is
"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
http://microformats.org/
. 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 200
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 cas
>>> 1 Jul 2008 6:28 Scott Reynen >>>
> 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 the con
t:
http://www.flurry.com
--- Original Message ---
Date: Wed Jul 02 09:43:00 PDT 2008
From: Guillaume Lebleu <[EMAIL PROTECTED]>
To: Microformats Discuss
Subject: Re: [uf-discuss] Human and machine readable data format
---
Michael MD wrote:
> Allowing language conventions for date pa
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!
IMO, "2008-01-25" is indeed more human-readable than
"2008-01-25T12:00:11", but it is still less "human-hearable" than the
plain old English "January 25th, 2008", which is human-readable and
machine-readable as long as it is written following precisely English US
conventions and the locale can
Guillaume Lebleu wrote:
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 th
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
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 thos
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 i
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, ta
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
acc
>
> 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"
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:
6/30/08
* HTML 5
6/30/08
* RDFa
6/30/08.
If you are using XHTML 1.1+RDFa (served as application/xhtml+xml)
and you want it to be valid.
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 wh
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
On [Jun 30], at [ Jun 30] 11:11 , Jeremy Keith wrote:
I disagree. I think that writing:
5 minutes ago
...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 work 14:00.
The latter
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 cla
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
On Mon, 2008-06-30 at 16:16 +0100, Jeremy Keith wrote:
>
> On June 30th
> at 9.00am
>
Yes Jeremy I like this idea but...
its this bit I am having difficulty with
[...]
On June 30th
at 9.00am
[...]
semantically on their own the above does not mean much nothing at all
really, search engines,
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 that
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 wa
> 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
On Mon, 2008-06-30 at 07:57 +0100, Glenn Jones wrote:
> Jan 25 08
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
As we turnaround on the spot about machine data issue, the question of
Natural Language Processing (NPL) has come up again. The main problem
with any form of NLP is there are too many ambiguities in reading dates
or any other form of freeform human written text. I don't want us to go
down this pat
67 matches
Mail list logo
