From robertc at gmail.com Tue Jul 1 03:51:24 2008 From: robertc at gmail.com (Rob Crowther) Date: Tue Jul 1 04:48:24 2008 Subject: [uf-dev] A sensible alternative for representing dates In-Reply-To: <3be0bf100806300929y57b8bd5cy4c9dcfd9a64a663c@mail.gmail.com> References: <7e8d40920806300728k3456aaa1ubd86b8ffae7569d5@mail.gmail.com> <3be0bf100806300929y57b8bd5cy4c9dcfd9a64a663c@mail.gmail.com> Message-ID: <3ce2ebd20807010351u54f29746x761e7523e6b7ac64@mail.gmail.com> 2008/6/30 Jake Archibald : > > The problem with this is it requires an anchor, and requires the author to > build a meaningful page at that address. > I know this introduces another debate, but the author isn't required to build a meaningful page for rel-tag and this would work in exactly the same way. All we need is for one site to implement a 'datespace' (a Technorati style aggregator perhaps) and we could have: June 30, 2008 at 1:00 pm Rob From mail at tobyinkster.co.uk Sat Jul 5 13:17:34 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sat Jul 5 13:17:53 2008 Subject: [uf-dev] Human and machine readable data format Message-ID: <83EC58D7-DD08-48C7-BC38-13E4FC83859B@tobyinkster.co.uk> Glenn Jones wrote: > http://ufxtract.com/experimental/hm-readable-date.htm A problem which hasn't been raised with regards to this proposal is that even though you are proposing a fixed date format, because it *looks* like natural language, authors will assume that it *is* natural language, and simply start including dates in whatever format they like. Then you get an NLP "arms race" between publishers and parsers. If you don't believe that that will happen, take a look at what happened with RFC 822 dates, which are simply a mess. -- Toby A Inkster From glenn.jones at madgex.com Sun Jul 6 00:42:47 2008 From: glenn.jones at madgex.com (Glenn Jones) Date: Sun Jul 6 00:42:55 2008 Subject: [uf-dev] Human and machine readable data format In-Reply-To: <83EC58D7-DD08-48C7-BC38-13E4FC83859B@tobyinkster.co.uk> References: <83EC58D7-DD08-48C7-BC38-13E4FC83859B@tobyinkster.co.uk> Message-ID: <36A319113CF910438942741C4727ADFF0218B56E@MOBY.Clarence.local> Toby A Inkster wrote: > A problem which hasn't been raised with regards to this proposal is > that even though you are proposing a fixed date format, because it > *looks* like natural language, authors will assume that it *is* > natural language, and simply start including dates in whatever format > they like. Then you get an NLP "arms race" between publishers and > parsers. > If you don't believe that that will happen, take a look at what > happened with RFC 822 dates, which are simply a mess. Very true the more you make the date look like natural language, the less it looks like a fixed format. I really don't want us to get involved in any form of NLP, it just would not work. I think it was Mike who said that dates have to be parsed correctly, no level of error is acceptable. I don't want to travel to an event on the wrong day because a parser got the date wrong. I had not come across the whole RFC 822 standard, you are right what a mess. Dates do seem to be a recurring theme of pain for developers. Glenn Jones From ameer1234567890 at gmail.com Tue Jul 8 01:10:58 2008 From: ameer1234567890 at gmail.com (Ameer Dawood) Date: Tue Jul 8 01:11:00 2008 Subject: [uf-dev] hCalendar Creator and XHTML Message-ID: <19abcbf20807080110h5a05d8bflefa6c0c06d003ad9@mail.gmail.com> Hi, The hCalendar Creator at http://microformats.org/code/hcalendar/creator generates non-standard code for XHTML. XHTML does not support uppercase tag names as you all may know. The hCalendar creator generates uppercase tag names. Would someone please take the initiative to correct the tool. Ameer From brian.suda at gmail.com Tue Jul 8 01:26:25 2008 From: brian.suda at gmail.com (Brian Suda) Date: Tue Jul 8 01:26:27 2008 Subject: [uf-dev] hCalendar Creator and XHTML In-Reply-To: <19abcbf20807080110h5a05d8bflefa6c0c06d003ad9@mail.gmail.com> References: <19abcbf20807080110h5a05d8bflefa6c0c06d003ad9@mail.gmail.com> Message-ID: <21e770780807080126g51bebe74m8753ebc37639df2b@mail.gmail.com> 2008/7/8 Ameer Dawood : > Hi, > > The hCalendar Creator at > http://microformats.org/code/hcalendar/creator generates non-standard > code for XHTML. --- i just had a look and i don't seem to get any uppercase element names. Can you be more specific on which fields this is occurring? along with your browser and OS versions. It might be a JS problem, i can't seem to replicate this, so correcting it will be difficult. Thanks, -brian -- brian suda http://suda.co.uk From ameer1234567890 at gmail.com Wed Jul 9 09:34:46 2008 From: ameer1234567890 at gmail.com (Ameer Dawood) Date: Wed Jul 9 09:34:50 2008 Subject: [uf-dev] hCalendar Creator and XHTML In-Reply-To: <21e770780807080126g51bebe74m8753ebc37639df2b@mail.gmail.com> References: <19abcbf20807080110h5a05d8bflefa6c0c06d003ad9@mail.gmail.com> <21e770780807080126g51bebe74m8753ebc37639df2b@mail.gmail.com> Message-ID: <19abcbf20807090934w77c53af1n2c7c055abc50ec73@mail.gmail.com> Hi Brian, Yes, it does seem to be a javascript issue, as it works all right in Firefox. I am using Opera 9.5 on a Windows XP. Ameer On Tue, Jul 8, 2008 at 1:26 PM, Brian Suda wrote: > 2008/7/8 Ameer Dawood : >> Hi, >> >> The hCalendar Creator at >> http://microformats.org/code/hcalendar/creator generates non-standard >> code for XHTML. > > --- i just had a look and i don't seem to get any uppercase element > names. Can you be more specific on which fields this is occurring? > along with your browser and OS versions. It might be a JS problem, i > can't seem to replicate this, so correcting it will be difficult. > > Thanks, > -brian > > -- > brian suda > http://suda.co.uk > _______________________________________________ > microformats-dev mailing list > microformats-dev@microformats.org > http://microformats.org/mailman/listinfo/microformats-dev > From mail at tobyinkster.co.uk Sat Jul 19 07:13:31 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sat Jul 19 08:31:22 2008 Subject: [uf-dev] Embedded compound microformat edge case Message-ID: <52479B36-B0DE-4CF4-9291-E626C6CD82A0@tobyinkster.co.uk> Firstly to clarify, I use the term "nested" to cover the case where a microformat root element is contained within another microformat root element in DOM terms. e.g.

I use the term "embedded" to refer to a subset of these - where the nesting has a deliberate and established meaning. e.g.

or

Cognition has, since its first released version handle nested microformats fairly well. However, with embedded microformats it's had a major limitation, which I'm fixing for the next version. The limitation is that while this works fine:

the following will not:

It would be parsed as two completely separate hCards, of which the outer hCard would have an agent which is a simple string. As I said, I'm solving that for the next release. But I've come across a parsing edge case:

Should #x2 and #x3 both be treated as agents of #x1, or should #x2 be treated as an agent and #x3 be treated as a completely separate (nested) hCard? Or perhaps its *too* invalid and neither #x2 nor #x3 should be treated as agents. If both #x2 and #x3 are treated as agents, then what about this even stranger case which is differently nested, but semantically similar:

Right now I'm using the tactic that within

Only #x2 is the agent of #x1. #x3 is treated as an entirely separate hCard. If people want #x1 to have two agents, they can write:

or better yet:

What do other people think? PS: For simplification, I'm leaving out properties like "fn", but assume that they are present. -- Toby A Inkster From mail at tobyinkster.co.uk Sun Jul 20 13:08:14 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sun Jul 20 13:08:34 2008 Subject: [uf-dev] datetime attribute Message-ID: The next release of Cognition (and the current iteration of the web service) supports parsing datetime values from HTML's datetime attribute. This allows for: and also: at in HTML 5, but it also allows for some rather cool stuff with in HTML 4, such as my recent update to this page: http://examples.tobyinkster.co.uk/hcard ("Cognify" links in the footer to convert to different formats.) What do people think? I'll document my parsing technique soonish. -- Toby A Inkster From rff.rff at gmail.com Mon Jul 21 01:43:15 2008 From: rff.rff at gmail.com (gabriele renzi) Date: Mon Jul 21 01:43:18 2008 Subject: [uf-dev] Embedded compound microformat edge case In-Reply-To: <52479B36-B0DE-4CF4-9291-E626C6CD82A0@tobyinkster.co.uk> References: <52479B36-B0DE-4CF4-9291-E626C6CD82A0@tobyinkster.co.uk> Message-ID: <828083e70807210143k41467b9fucd7d456c682c905f@mail.gmail.com> Did you find these in the wild or just testing ? If we are just talking about theoretical things why not restrict the agent field to actually be agent+vcard? It greatly simplifies parsing and it doesn't seem limiting for authors. And, what is the expected behaviour in similar cases such as hListing's lister+vcard, hresume's affiliation+vcard,contact+vcard and so on ? From mail at tobyinkster.co.uk Mon Jul 21 13:36:31 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Mon Jul 21 13:36:49 2008 Subject: [uf-dev] Embedded compound microformat edge case Message-ID: Gabriele Renzi wrote: > Did you find these in the wild or just testing ? Just testing. > If we are just talking about theoretical things why not restrict the > agent field to actually be agent+vcard? It greatly simplifies parsing > and it doesn't seem limiting for authors. Do you mean insisting on the "agent" class and "vcard" class being on the same element? All versions of Cognition up to and including alpha 10 *do* insist on that, but in fact a lot of examples in the wild actually nest the vCard *within* the agent (i.e. not on the same element), which is why I've been working on changing things for the next release. It's not such a problem with agent vCards, as agent is used fairly rarely in the wild (even though it's actually quite a useful property) - possibly because people don't know about it, and possibly because there are quite a few parsers that screw things up, copying some of the agent's details to the main hCard's details. But there are other embedded microformats (e.g. hCard and hCalendar events within hReview items; hCards within hAudio contributors; etc) which are more common, so it's important to get this right. As I say, the specific case which I mentioned, along the lines of:

Is very much an edge case, but it would be nice if we had a normative interpretation of it. Right now I'm saying that the first hCard is the real agent and the second is a separate hCard. If people really need two agents, then they should use:

-- Toby A Inkster