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
On 05/05/2007, at 3:29 AM, Andy Mabbett wrote:
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 wro
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 he
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:
Fromage
Where's the visible data there? By your logic, tags should only
work on
the anchor element's content, not the tai
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
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:
Fromage
Where's the visible data there? By your logic, tags should only work on
the anc
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
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 t
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 d
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 their calendar
> program for example)
No the "i
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.
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
On May 3, 2007, at 5:57 PM, 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
Tantek Çelik wrote:
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
in
(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 q
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" i
At 3:10 AM +0100 4 05 2007, Patrick H. Lauke wrote:
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
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.
July
julio
7 月
июль
good point ...
parsing it might end up needing a database of day a
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 so
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, an
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? Let
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
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.
July
julio
7 月
июль
good point ...
parsing it might end up needing a database of day and month names and
character sets and numbers in eve
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
Breton Slivka wrote:
July 26th,
2005
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: l10n/i18n. They require displayed machine values to
be in English.
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: assumin
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 spec
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 hca
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 microformat-consum
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
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
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 l
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 th
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. Why
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 b
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 mac
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 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 princip
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 l
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 ambigu
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 ve
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
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 together.
From: "James Craig" <[EMAIL PROTECTED]>
To: "Microformats Discuss"
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 isn
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
f
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
formats rather than tryi
46 matches
Mail list logo