MM/DD is bad! What's 07/05 ? Today is 05/04 ... or is it 04/05 ?
Tomorrow is cool :)
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
On 04/05/07, Tantek Çelik [EMAIL PROTECTED] wrote:
Human readable to one culture/language is not necessarily human readable to
other cultures/languages.
I agree that i18n is a stumbling block here. But, descriptions, titles
and names aren't translated as well, why would the date need be?
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,
I agree that i18n is a stumbling block here. But, descriptions, titles
and names aren't translated as well, why would the date need be? Let's
put the smarts into the parsers and figure out which date we mean, and
have the user confirm it.
The place for such user confirmation is in authoring
On May 4, 2007, at 3:29 AM, Breton Slivka 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=enJuly/span
span class=vmonth lang=esjulio/span
span class=vmonth
On 5/3/07 7:10 PM, Patrick H. Lauke [EMAIL PROTECTED] wrote:
But to bring it back to the original argument, the routine extraction
does not necessarily have to equate to data visible in, say, a tooltip.
The routine extraction may well be mediated via some machine interpretation.
May is
(apologies for top posting but this is in response to Al's entire message,
not to any specific point in particular)
Al,
VERY well written. That's perhaps the clearest explanation I have seen of
why it is important to have visible information, even somewhat visible
rather than invisible.
May I
I almost completely disagree with this. If people are actually
*using* Microformats as intended, there will be plenty of times when
the machine data will pass in front of the user (in their calendar
program for example) for verification. I do however, agree with the
following.
expressed
Scott Reynen wrote:
Tantek Çelik wrote:
To minimize the negative impact of that violation, the datetime
design
pattern does two things:
1. Keep both copies of the data on the same element (the further
apart two
copies of data, the greater the chance that that copies will
diverge).
2.
On 5/4/07 8:19 AM, James Craig [EMAIL PROTECTED] wrote:
Copied the entire email below for context. Tantek, if you post this
to the wiki, please note it as opinion and give a link to the thread.
Marking this as fact would misrepresent the views of the Microformats
group as a whole.
I disagree
On May 4, 2007, at 8:24 AM, Tantek Çelik wrote:
On 5/4/07 8:19 AM, James Craig [EMAIL PROTECTED] wrote:
I almost completely disagree with this. If people are actually
*using* Microformats as intended, there will be plenty of times when
the machine data will pass in front of the user (in
In message [EMAIL PROTECTED], Tantek Çelik
[EMAIL PROTECTED] writes
On 5/4/07 8:19 AM, James Craig [EMAIL PROTECTED] wrote:
I almost completely disagree with this. If people are actually
*using* Microformats as intended, there will be plenty of times when
the machine data will pass in front
In message [EMAIL PROTECTED], Tantek Çelik
[EMAIL PROTECTED] writes
Al's explanation provides good reasons *in general* why visible data
works (and why invisible does not work),
Hmm.
Consider:
a href=cheese lang=frFromagea
Where's the visible data there? By your logic, tags should
In message [EMAIL PROTECTED], Breton
Slivka [EMAIL PROTECTED] writes
It seems to me that in order to more effectively solve this problem,
this set of restrictions should be clarified- Here's what I've got so
far, correct me if I'm wrong.
Date markup must:
1 be capable of marking up dates
Andy Mabbett wrote:
Tantek Çelik writes
Al's explanation provides good reasons *in general* why visible data
works (and why invisible does not work),
Consider:
a href=cheese lang=frFromagea
Where's the visible data there? By your logic, tags should only
work on
the anchor
Scott Reynen wrote:
I'd invite you to document the list of every possible way to represent
each month in plain text, and then let us know if you still think
reading through such a list to figure out how to publish dates is easier
for publishers.
Maybe I've lost track of the original issue
On May 4, 2007, at 2:42 PM, Patrick H. Lauke wrote:
I'd invite you to document the list of every possible way to
represent each month in plain text, and then let us know if you
still think reading through such a list to figure out how to
publish dates is easier for publishers.
Maybe I've
iso date isn't necessarily required when someone enters a date (i.e.
saying 24th June doesn't translate into a single date, neither does
'thursday'). Shouldn't the focus be on trying to standardise date
I'm normally all for liberalness in parsing but NOT when the intended
meaning becomes
Looks to me that we have these goals:
* Specify a date in a format that a machine can understand (i.e. the
ISO8601 format)
* Stash it somewhere where it's legal to do so, and is not apparent
to human readers
I'm still undecided whether a full ISO date is abbreviable as a normal
date, but looks
On 5/3/07 1:40 AM, victor jalencas [EMAIL PROTECTED] wrote:
* Stash it somewhere where it's legal to do so
valid would be more precise rather than legal
and is not apparent to human readers
To be clear, this clause, in the absolute, is undesirable. That is, in
following the principles of
Tantek Çelik wrote:
To be clear, this clause, in the absolute, is undesirable. That is, in
following the principles of microformats, the date needs to be at least
somewhat *visible* to humans, rather than invisible.
But not the machine-readable part, if it makes no sense to the human reader.
On 03/05/07, Patrick H. Lauke [EMAIL PROTECTED] wrote:
Tantek Çelik wrote:
To be clear, this clause, in the absolute, is undesirable. That is, in
following the principles of microformats, the date needs to be at least
somewhat *visible* to humans, rather than invisible.
But not the
victor jalencas wrote:
Since using ISO8601 is a w3c recommendation, I wondered where
specifically they were recommending its use. Looks like there is an
element (a couple of them, actually) with an attribute that can
legally contain an ISO datetime: INS and DEL.
Technically, that should only
Tantek Çelik wrote:
and is not apparent to human readers
To be clear, this clause, in the absolute, is undesirable. That is, in
following the principles of microformats, the date needs to be at least
somewhat *visible* to humans, rather than invisible.
I still don't understand this part.
On May 3, 2007, at 12:23 PM, Tantek Çelik wrote:
and is not apparent to human readers
To be clear, this clause, in the absolute, is undesirable. That
is, in
following the principles of microformats, the date needs to be at
least
somewhat *visible* to humans, rather than invisible.
I
On 5/3/07 10:48 AM, victor jalencas [EMAIL PROTECTED] wrote:
On 03/05/07, Patrick H. Lauke [EMAIL PROTECTED] wrote:
Tantek Çelik wrote:
To be clear, this clause, in the absolute, is undesirable. That is, in
following the principles of microformats, the date needs to be at least
somewhat
On 5/3/07 2:50 PM, Scott Reynen [EMAIL PROTECTED] wrote:
On May 3, 2007, at 12:23 PM, Tantek Çelik wrote:
and is not apparent to human readers
To be clear, this clause, in the absolute, is undesirable. That
is, in
following the principles of microformats, the date needs to be at
least
On 5/3/07 1:14 PM, Jon Gibbins (dotjay) [EMAIL PROTECTED] wrote:
Tantek Çelik wrote:
and is not apparent to human readers
To be clear, this clause, in the absolute, is undesirable. That is, in
following the principles of microformats, the date needs to be at least
somewhat *visible* to
Tantek Çelik wrote:
2. Keep both copies of the data at least somewhat visible to humans so that
at least *some* human eyes/ears can easily inspect both copies and ensure
that they have not diverged.
For the sake of argument, though: assuming that those human eyes/ears
use a
This is a very difficult problem. Difficult problems need as many
potential solutions as possible to be presented- The more solutions,
the more chance of arriving at a good one. The tricky part here is
creating a solution which is in line with common usage.
It seems to me that by basing
I should perhaps add that my solution must also violate either
restriction 3, or 4- that is, you can hide the year element with CSS.
If you leave it visible, then it may follow common usage in a lot of
situations. Or you might end up using a year in situations where you
may not usually
At 12:24 AM +0100 4 05 2007, Patrick H. Lauke wrote:
Tantek Çelik wrote:
2. Keep both copies of the data at least somewhat visible to humans so that
at least *some* human eyes/ears can easily inspect both copies and ensure
that they have not diverged.
For the sake of argument, though:
Breton Slivka wrote:
span class=vmonthJuly/span span class=vday26/spanth,
span class=vyear2005/span
This solution is certainly more verbose, but note that it follows
all restrictions except for 7.
I don't think this will work, for the same reason tel-type and adr-
type don't work:
Al Gilman wrote:
If the machineable info is not routinely passing through the
consciousness of the communicating principals (that is, people),
Who may, without the machine-mediated interpretation, not actually be
able to make a qualitative judgement (e.g. if I see a geo lat/long value
, I'm
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=enJuly/span
span class=vmonth lang=esjulio/span
span class=vmonth lang=jp7 月/span
span class=vmonth lang=ruиюль/span
Tim Parkin wrote:
With all of the discussion about iso dates being unreadable and
that an
iso date isn't necessarily required when someone enters a date (i.e.
saying 24th June doesn't translate into a single date, neither does
'thursday'). Shouldn't the focus be on trying to standardise date
From: James Craig [EMAIL PROTECTED]
To: Microformats Discuss microformats-discuss@microformats.org
Sent: Thursday, May 03, 2007 8:56 AM
Subject: Re: [uf-discuss] human readable date parsing
Tim Parkin wrote:
With all of the discussion about iso dates being unreadable and that an
iso date
Paul Wilkins wrote:
What if the value class was to be used with a hidden class. Then they
would serve their purpose, they wouldn't interfere with existing styles
and could be interpreted correctly.
.hidden {display: hidden}
Then the human-readable and machine-readable can be mashed
James Craig wrote:
Tim Parkin wrote:
With all of the discussion about iso dates being unreadable and that an
iso date isn't necessarily required when someone enters a date (i.e.
saying 24th June doesn't translate into a single date, neither does
'thursday'). Shouldn't the focus be on trying
James Craig wrote:
Tim Parkin wrote:
[...] Shouldn't the focus be on trying to standardise date
formats rather than trying to hide the iso date? If we can get a parser
to recognise 'human readable' dates (which *is* possible, if not totally
easy, http://labix.org/python-dateutil for a python
40 matches
Mail list logo
