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
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
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 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
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
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
On Mon, Jun 30, 2008 at 5:54 PM, Dan Brickley [EMAIL PROTECTED] wrote:
Breton Slivka wrote:
I think this sort of counter argument is a straw man. The proposal
from Guillaume was not to write a natural language parser that can
parse any kind of human written date. The proposal was to parse
the restrictions:
1. No information hiding
2. Humans first, machines second.
3. It must be in a format that's easily machine parsable.
You see the problem here? You guys are going to have to comprimise on
one of these three damned restrictions, or face irrelevance!
I suggests a 4th
On Tue, Jul 1, 2008 at 9:49 AM, Breton Slivka [EMAIL PROTECTED] wrote:
On Tue, Jul 1, 2008 at 3:11 AM, Ben Ward [EMAIL PROTECTED] wrote:
I'd like to make a very important point.
On 30 Jun 2008, at 10:38, Breton Slivka wrote:
if you violate #1, Tantek steps
in and says you can't do
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,
I think this sort of counter argument is a straw man. The proposal
from Guillaume was not to write a natural language parser that can
parse any kind of human written date. The proposal was to parse a very
specific and standardized format of date. If one were to write
Oktober, the specified
the restrictions:
1. No information hiding
2. Humans first, machines second.
3. It must be in a format that's easily machine parsable.
You see the problem here? You guys are going to have to comprimise on
one of these three damned restrictions, or face irrelevance!
To continue- the
I think what was intended, was rather than try to write a parser that
picks up most styles of natural language dates, as you suggest-
Instead write a parser that only picks up one or two standard styles
of dates. Much like the style guides that are used in academia for
writing standard forms of
I would say that a relational database would be the best option here-
if it weren't for SQL. It seems all these suggestions are all more
about avoiding the pain of dealing with SQL than doing the right
thing. The fact is, that microformat attributes all have well defined
relations which can easily
sorry for busting in late on this conversation, but let me get this
straight, I'm not sure I follow.
1. You guys are proposing a radical change in microformats, and in
the way microformats work, and have given us just a week to discuss/
object
2. If radical change is implemented in firefox,
elements?
example:
x-mozilla-add-hcard {
visibility:visible;
background:orange;
border: 1px solid black;
}
which would select whatever element is the button/link for adding an
hcard.
-breton
On 04/09/2007, at 9:50 PM, Pelle W wrote:
Breton Slivka wrote:
1. You guys are proposing
as stated before, proposals go on microformats-new, not this list.
Aside from that- microformats tend to be based on existing practice.
Wouldn't it be nice if people stated their assumptions straight off?
Microformats or no. Unfortunately, the persuasive power of many
arguments depend on
I believe it was agreed to use the also stalled hCite instead.
-Breton
On 15/05/2007, at 7:03 PM, Ottevanger, Jeremy wrote:
Dear all,
Raising my head above what I hope is the correct parapet to ask, does
anyone know if Tim Gambell, who was seemingly leading work on the
proposed work-of-art
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,
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
specify a year, violating the common usage in that
situation. If you hide it, then you violate 3. But, the choice of
which principle to violate is left in the hands of the author.
On 04/05/2007, at 9:49 AM, Breton Slivka wrote:
This is a very difficult problem. Difficult problems need as many
If I remember correctly, these issues can be dealt with by using an
a element instead of an object element. This is endorsed in the
spec for the pattern, I believe.
On 05/02/2007, at 4:00 PM, Jason Karns wrote:
I have two issues with the include-pattern, though they are less
with the
On Jan 4, 2007, at 8:52 AM, Brian Suda wrote:
On 1/4/07, Breton Slivka [EMAIL PROTECTED] wrote:
div class=vcard
span class=fnAbraham Lincoln/span
div class=orgUnited States/div
div class=adr
div class=street-address1600 Pennsylvania Ave./div
span class=localityWashington/span
,
span
On Dec 29, 2006, at 11:54 AM, Andy Mabbett wrote:
In message [EMAIL PROTECTED],
Breton
Slivka [EMAIL PROTECTED] writes
There's a few rather obvious problems with this idea that I can see.
However, before I point them out, I will note that if the benefits of
such a plan outweigh
On Jan 3, 2007, at 8:26 PM, Tantek Çelik wrote:
The big difference here (in contrast to Usenet, other lists etc.)
is that
this community has retained a remarkably positive and inviting tone of
discussion for quite a long time, much much more so than those
other forums,
and those involved
There's a few rather obvious problems with this idea that I can see.
However, before I point them out, I will note that if the benefits of
such a plan outweigh the problems, then go for it. However I suggest
very carefully thinking about this before going nuts with extensions.
#1. More
Lead by example. If you can get some use out of authoring your own
xhtml semantics, do it!
Document your process, add it to the appropriate wiki pages. The
citation format suffers so much from rhetorical discussion, that I
think an account of actual experience in implementation would do
norman walsh recently posted inn his blog about this very issue
http://norman.walsh.name/2006/04/13/validatingMicroformats
___
microformats-discuss mailing list
microformats-discuss@microformats.org
I mostly agree with tantek, but I would like to point out a few more
things to look at as far as this sort of effort goes.
XSLT provides more than enough power to describe and extract
information out of pages with microformats embedded. x2v demonstrates
this. If you're looking for a single
Allow me to point you directly to the GRDDL site.
http://www.w3.org/TeamSubmission/grddl/
Along with xmdp, I believe it thoroughly addresses all the issues you
raise about as well as they can possibly be addressed.
On Mar 30, 2006, at 4:01 PM, Joe Reger, Jr. wrote:
before having the
Yes, as a matter of fact, I do. The w3c.
Thanks, I completely agree. What I'm looking for is the best way to
get some degree of sanctioning of RDF/XMLSchema/XSL/whatever and then
use that sanctioning to gain toolmaker adoption. It would seem to me
that this mailing list is the place to do
This is where you have completely lost me. You are not making it
particularly clear what problem it is that you actually want to solve.
Here's some more links. I truly believe this problem is much smaller
than you believe it is.
http://dannyayers.com/2005/08/01/microformats-on-the-grddl/
it to! So you make additional
microformats to solve the domain specific issues. Thus the micro in
microformats, as I understand it.
On Mar 29, 2006, at 12:13 PM, Alf Eaton wrote:
On 29 Mar 2006, at 14:02, Breton Slivka wrote:
If we are for the moment to entertain the idea of modularization
I've only just recently figured out what xmdp's are, and what they're
capable of. I notice the structure of your hcard/hreview/hcalendar
thing is such that you can pick an attribute, and search for bits of
data which contain that attribute. Have you attempted to detect and
parse XMDP's
35 matches
Mail list logo
