From mikeschinkel at gmail.com Sat Mar 3 23:53:53 2007 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Sat Mar 3 23:54:14 2007 Subject: [uf-dev] Re: [uf-discuss] XOXO to JSON and back In-Reply-To: References: <6CE341F8-D3A2-4F26-AC80-CB8C854796CF@mac.com> Message-ID: <000001c75e32$4b2d3c60$2102fea9@Guides.local> Kevin Marks wrote: > A preliminary go at a bidirectional XOXO to JSON service: > > http://kevinmarks.com/cgi-bin/xoxotojson.py?url=http://kevinmarks.com > > and back again: > > http://kevinmarks.com/cgi-bin/jsontoxoxo.py?url=http%3A// > kevinmarks.com/cgi-bin/xoxotojson.py%3Furl%3Dhttp%3A//kevinmarks.com > > change the url parameters as it suits you, let me know what > you think Nice. Are you releasing the Python code, or just offering the service? -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us "It never ceases to amaze how many people will proactively debate away attempts to improve the web..." From kevinmarks at mac.com Sun Mar 4 00:52:00 2007 From: kevinmarks at mac.com (Kevin Marks) Date: Sun Mar 4 00:52:02 2007 Subject: [uf-dev] Re: [uf-discuss] XOXO to JSON and back In-Reply-To: <000001c75e32$4b2d3c60$2102fea9@Guides.local> References: <6CE341F8-D3A2-4F26-AC80-CB8C854796CF@mac.com> <000001c75e32$4b2d3c60$2102fea9@Guides.local> Message-ID: On Mar 3, 2007, at 11:53 PM, Mike Schinkel wrote: > > Nice. Are you releasing the Python code, or just offering the service? Sure, I can release the python (though it's basically just glueing xoxo.py and simplejson.py together) http://kevinmarks.com/xoxotojson.py http://kevinmarks.com/jsontoxoxo.py http://kevinmarks.com/xoxo.py From mikeschinkel at gmail.com Sun Mar 4 01:01:07 2007 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Sun Mar 4 01:01:14 2007 Subject: [uf-dev] Re: [uf-discuss] XOXO to JSON and back In-Reply-To: References: <6CE341F8-D3A2-4F26-AC80-CB8C854796CF@mac.com><000001c75e32$4b2d3c60$2102fea9@Guides.local> Message-ID: <001301c75e3b$a61824b0$2102fea9@Guides.local> Cool! > -----Original Message----- > From: microformats-dev-bounces@microformats.org > [mailto:microformats-dev-bounces@microformats.org] On Behalf > Of Kevin Marks > Sent: Sunday, March 04, 2007 3:52 AM > To: A list for people developing tools with microformats. > Subject: Re: [uf-dev] Re: [uf-discuss] XOXO to JSON and back > > > On Mar 3, 2007, at 11:53 PM, Mike Schinkel wrote: > > > > > Nice. Are you releasing the Python code, or just offering > the service? > > Sure, I can release the python (though it's basically just > glueing xoxo.py and simplejson.py together) > > http://kevinmarks.com/xoxotojson.py > http://kevinmarks.com/jsontoxoxo.py > http://kevinmarks.com/xoxo.py > > _______________________________________________ > microformats-dev mailing list > microformats-dev@microformats.org > http://microformats.org/mailman/listinfo/microformats-dev From tantek at cs.stanford.edu Sun Mar 4 20:40:18 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Sun Mar 4 20:38:30 2007 Subject: [uf-dev] (redirecting to microformats-dev) Re: [uf-discuss] Scraping or parsing? In-Reply-To: <001201c75f5f$fe041240$116bacca@COMCEN> Message-ID: Please redirect discussions of "parsing" and other development related/centric topics to the microformats-dev list per: http://microformats.org/wiki/mailing-lists#Bad_topics_for_discussion http://microformats.org/wiki/mailing-lists#microformats-dev Thanks! Tantek On 3/5/07 11:53 AM, "Michael MD" wrote: > >> Users should *not* be >> encouraged >> to publish HTML markup they cannot read. > > That been happening out there in the real world with html for years with > wysiwyg editors! > ... and the fact that some of them generate bad or bloated markup is not > going to stop the masses from using them. > > Personally I think it would be nice to see authoring tools for microformats > built into wysiwyg editors > .... I'm sure its coming soon... > > - I even had a go last year at modifying a javascript-based html editor to > auto-detect hcards and vevents and allow authoring and editing of them with > simple forms but decided I needed to learn to optimize javascript better > first (it was way too slow!) ... anything designed for "the masses" to use > must be fast enough to for an impatient person on an old slow machine! > > > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From frankie at frankieroberto.com Wed Mar 21 15:59:15 2007 From: frankie at frankieroberto.com (frankie roberto) Date: Wed Mar 21 15:59:17 2007 Subject: [uf-dev] hCalendar microformat implementation - TV channels as location? Message-ID: <1350f7a40703211659u10a7c628r6ced8c5ca106fb15@mail.gmail.com> Hi all, Not sure if this is the right place to post this, but I've implemented the hCalendar microformat on a website, and wanted to ask for feedback about how I've used it. You can see the website here: http://www.ontvtonight.co.uk/ - It's quite a simple daily digest of things worth watching on telly (according to me!), and where things appear, I've used the hCalendar microformat. There's a page explaining this too here: http://www.ontvtonight.co.uk/microformats The main question is whether it's acceptable to use the TV channel as the 'location'. It's clearly not a physical location (which screws Google Calendar up when it tries to do a Google Local search for it), but is the more abstract sense of being a location (eg 'location on the dial') acceptable? Are there any alternatives? I saw this come up on the main mailing list a while back (in the discussion about microformats on the BBC's new radio schedules pages), but didn't see any real conclusion on this issue. If anyone has any thoughts on this, or any other aspect of my implementation, I'd be interested to hear them. Cheers, Frankie Roberto -------------- next part -------------- An HTML attachment was scrubbed... URL: http://microformats.org/discuss/mail/microformats-dev/attachments/20070321/8ef9b634/attachment.html From andy at pigsonthewing.org.uk Thu Mar 22 09:14:37 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Mar 22 14:08:36 2007 Subject: [uf-dev] Suggested new parsing rule for alt text Message-ID: I suggest that this rule be adopted, for *all* microformats, unless there are good reasons for specific exceptions: Where an element contains only an image element, and the parser is expecting text, the alt text of the image should be used. For example:

Acme

should be equivalent of the currently-permissible:

Acme

or

Acme

It will facilitate the microformatting of templated CMS data (not least that in Wikipedia), which allow either text or image data in a field. It will also be particularly relevant where images of text are used. Can anyone foresee any problems with that? -- Andy Mabbett Welcome to the world's longest week! From andy at pigsonthewing.org.uk Thu Mar 22 09:14:16 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Mar 22 14:08:36 2007 Subject: [uf-dev] hCard DoB -> calendar apps Message-ID: Are there any hCard parsers, which will add a name/ DoB pair from an hCard, to a calendar application, as a recurring iCalendar event? Is this something Operator might do? Other fields, such as "adr", might be added as a "note". -- Andy Mabbett Welcome to the world's longest week! From chris at placenamehere.com Thu Mar 22 14:56:27 2007 From: chris at placenamehere.com (Chris Casciano) Date: Thu Mar 22 14:56:44 2007 Subject: [uf-dev] hCard DoB -> calendar apps In-Reply-To: References: Message-ID: On Mar 22, 2007, at 1:14 PM, Andy Mabbett wrote: > > Are there any hCard parsers, which will add a name/ DoB pair from an > hCard, to a calendar application, as a recurring iCalendar event? > > Is this something Operator might do? > > Other fields, such as "adr", might be added as a "note". Is this the domain of the hcard parser, or the consumer of the extracted data? My first reaction would be the later. [For example, one can set birthdays on contacts in Apple's Address Book to automatically display in iCal] -- [ Chris Casciano ] [ chris@placenamehere.com ] [ http://placenamehere.com ] From lists at allinthehead.com Fri Mar 23 01:30:10 2007 From: lists at allinthehead.com (Drew McLellan) Date: Fri Mar 23 01:30:17 2007 Subject: [uf-dev] Suggested new parsing rule for alt text In-Reply-To: References: Message-ID: <4F941988-B3FA-4189-8715-B4011A7E4454@allinthehead.com> On 22 Mar 2007, at 17:14, Andy Mabbett wrote: > I suggest that this rule be adopted, for *all* microformats, unless > there are good reasons for specific exceptions: > > Where an element contains only an image element, and the > parser > is expecting text, the alt text of the image should be used. tbh I though that this was already a rule. It's a rule native to HTML, so we therefore inherit it for free. It certainly seems like common sense, and I believe hKit already behaves in this way. drew. From sid at sidisinsane.com Fri Mar 23 02:31:24 2007 From: sid at sidisinsane.com (sid jansen) Date: Fri Mar 23 02:31:29 2007 Subject: [uf-dev] Suggested new parsing rule for alt text In-Reply-To: <4F941988-B3FA-4189-8715-B4011A7E4454@allinthehead.com> References: <4F941988-B3FA-4189-8715-B4011A7E4454@allinthehead.com> Message-ID: <1f5622610703230331w4b49f87cgfdee2207241aadd1@mail.gmail.com> 2007/3/23, Drew McLellan : > > On 22 Mar 2007, at 17:14, Andy Mabbett wrote: > > > I suggest that this rule be adopted, for *all* microformats, unless > > there are good reasons for specific exceptions: > > > > Where an element contains only an image element, and the > > parser > > is expecting text, the alt text of the image should be used. > > tbh I though that this was already a rule. It's a rule native to > HTML, so we therefore inherit it for free. > > It certainly seems like common sense, and I believe hKit already > behaves in this way. > > drew. > > _______________________________________________ > microformats-dev mailing list > microformats-dev@microformats.org > http://microformats.org/mailman/listinfo/microformats-dev > I disagree. By using the h1-tag you are already announcing that the enclosed data will be text data, just as the img-tag announces upcoming picture-data. So, even the use of the img-tag within any kind of heading is semantically incorrect html. In addition, the alt-attribute is meant as, in this case, non-text-equivalent to compensate reading-disabilities (More here: w3.org/TR/WCAG10-TECHS/#def-text-equivalent), not to add additional or even false information to a non-text element. The reason for wanting to place an img-tag within a heading is of course a pure matter of style, which can easily be achieved by one of the numerous Image-Replacement techniques (Actually they're Text-Replacement techniques. A list you can find here: mezzoblue.com/tests/revised-image-replacement) which add the desired image as a background defined in the stylesheet, rather than polluting the html file with misleading markup. So, the problem of your example is that I believe your approach is wrong and unnecessary. Sid. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://microformats.org/discuss/mail/microformats-dev/attachments/20070323/d6fe5ed2/attachment.html From lists at allinthehead.com Fri Mar 23 03:30:04 2007 From: lists at allinthehead.com (Drew McLellan) Date: Fri Mar 23 03:30:11 2007 Subject: [uf-dev] Suggested new parsing rule for alt text In-Reply-To: <1f5622610703230331w4b49f87cgfdee2207241aadd1@mail.gmail.com> References: <4F941988-B3FA-4189-8715-B4011A7E4454@allinthehead.com> <1f5622610703230331w4b49f87cgfdee2207241aadd1@mail.gmail.com> Message-ID: <36146F6C-0ECD-4114-98A0-35485DE9A843@allinthehead.com> On 23 Mar 2007, at 10:31, sid jansen wrote: >> 2007/3/23, Drew McLellan : >> On 22 Mar 2007, at 17:14, Andy Mabbett wrote: >> >> > I suggest that this rule be adopted, for *all* microformats, unless >> > there are good reasons for specific exceptions: >> > >> > Where an element contains only an image element, and the >> > parser >> > is expecting text, the alt text of the image should be >> used. >> >> tbh I though that this was already a rule. It's a rule native to >> HTML, so we therefore inherit it for free. >> >> It certainly seems like common sense, and I believe hKit already >> behaves in this way. >> >> drew. >> > > I disagree. > > By using the h1-tag you are already announcing that the enclosed > data will be text data, just as the img-tag announces upcoming > picture-data. The proposal Andy made relates only to the IMG element. Please focus on the issue being discussed. > So, even the use of the img-tag within any kind of heading is > semantically incorrect html. In addition, the alt-attribute is > meant as, in this case, non-text-equivalent to compensate reading- > disabilities (More here: w3.org/TR/WCAG10-TECHS/#def-text- > equivalent), not to add additional or even false information to a > non-text element. > > The reason for wanting to place an img-tag within a heading is of > course a pure matter of style, which can easily be achieved by one > of the numerous Image-Replacement techniques (Actually they're Text- > Replacement techniques. A list you can find here: mezzoblue.com/ > tests/revised-image-replacement) which add the desired image as a > background defined in the stylesheet, rather than polluting the > html file with misleading markup. > > So, the problem of your example is that I believe your approach is > wrong and unnecessary. You may have all day to debate the pros and cons of an off-the-cuff example, but others do not. The issue being discussed is whether microformats parsers should take the ALT attribute of an IMG element to be a textual equivalent of an image. My assertion is that this rule exists in HTML, and therefore becomes an implicit rule of parsing microformats. Presuming to lecture people on this list about the ALT attribute and Image Replacement techniques is near tantamount to trolling, in my personal opinion. Please do try to avoid unnecessary conversational tangents - it doesn't move us forward. drew. From brian.suda at gmail.com Fri Mar 23 03:47:42 2007 From: brian.suda at gmail.com (Brian Suda) Date: Fri Mar 23 03:47:45 2007 Subject: [uf-dev] Suggested new parsing rule for alt text In-Reply-To: References: Message-ID: <21e770780703230447v70b1b224ib2ce2cd8fee3101a@mail.gmail.com> On 3/22/07, Andy Mabbett wrote: > > I suggest that this rule be adopted, for *all* microformats, unless > there are good reasons for specific exceptions: > > Where an element contains only an image element, and the parser > is expecting text, the alt text of the image should be used. > > For example: > >

Acme

> > should be equivalent of the currently-permissible: > >

Acme

--- i would disagree. If the author wants the ALT attribute of the IMG element to be the FN value then there are two choices. 1) move the class="fn org" to the IMG element. THEN the ALT attribute would be correctly used as the value 2) add a class="value" to the IMG element then the ALT attribute would be picked-up by the parsers and used at the FN value. > Can anyone foresee any problems with that? --- plenty. This is an edge-case and leads to a slippery slop of LOTS of what if's. What if there are 2 elements? what if there is no ALT element? what if it is an element? what if it is an ? What if the DOM updates the H1 at a later time, what about sIFR, ... If the author can already mark-up the

element, how hard is it to mark-up the ? the more complexity we layer into these parsing rules for very little benefit, the more bugs, errors, problems we introduce. I don't see a significant advantage for just a small optimization, which can cause more problems that it is worth. -brian -- brian suda http://suda.co.uk From scott at randomchaos.com Thu Mar 22 15:28:12 2007 From: scott at randomchaos.com (Scott Reynen) Date: Fri Mar 23 04:35:15 2007 Subject: [uf-dev] hCard DoB -> calendar apps In-Reply-To: References: Message-ID: On Mar 22, 2007, at 5:56 PM, Chris Casciano wrote: > On Mar 22, 2007, at 1:14 PM, Andy Mabbett wrote: > >> Are there any hCard parsers, which will add a name/ DoB pair from an >> hCard, to a calendar application, as a recurring iCalendar event? >> >> Is this something Operator might do? >> >> Other fields, such as "adr", might be added as a "note". > > Is this the domain of the hcard parser, or the consumer of the > extracted data? > > My first reaction would be the later. > > [For example, one can set birthdays on contacts in Apple's Address > Book to automatically display in iCal] A third alternative would be to treat it as the responsibility (and authority) of the publisher, who could markup the birthday as a repeating event with hCalendar. Peace, Scott From andy at pigsonthewing.org.uk Fri Mar 23 04:41:14 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Fri Mar 23 07:03:49 2007 Subject: [uf-dev] Suggested new parsing rule for alt text In-Reply-To: <21e770780703230447v70b1b224ib2ce2cd8fee3101a@mail.gmail.com> References: <21e770780703230447v70b1b224ib2ce2cd8fee3101a@mail.gmail.com> Message-ID: <2wDnlMOqr8AGFwHk@pigsonthewing.org.uk> In message <21e770780703230447v70b1b224ib2ce2cd8fee3101a@mail.gmail.com>, Brian Suda writes >> I suggest that this rule be adopted, for *all* microformats, unless >> there are good reasons for specific exceptions: >> >> Where an element contains only an image element, and the parser >> is expecting text, the alt text of the image should be used. >> Can anyone foresee any problems with that? >What if there are 2 elements? Concatenate the alt texts, in the order they occur, with a space between them. > what if there is no ALT element? Treat as we would presently treat:

>what if it is an element? what if it is an >? My proposal relates specifically to ; my experience of using object and area are too limited for me to comment. I'm sure others can. >What if the DOM updates the H1 at a later time, What if the DOM updates any other part of a microformat? > what about sIFR "Scalable Inman Flash Replacement"? As for and . >If the author can You excised the relevant part of my post: It will facilitate the microformatting of templated CMS data (not least that in Wikipedia) In CMSs, the author often *cannot*. > the more complexity we layer into these parsing >rules for very little benefit, the more bugs, errors, problems we >introduce. Your "very little benefit" is hypothetical and unfounded. -- Andy Mabbett Welcome to the world's longest week! From andy at pigsonthewing.org.uk Fri Mar 23 05:04:38 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Fri Mar 23 07:03:49 2007 Subject: [uf-dev] hCard DoB -> calendar apps In-Reply-To: References: Message-ID: In message , Scott Reynen writes >>> Are there any hCard parsers, which will add a name/ DoB pair from an >>> hCard, to a calendar application, as a recurring iCalendar event? >A third alternative would be to treat it as the responsibility (and >authority) of the publisher, who could markup the birthday as a >repeating event with hCalendar. I thought the order of priority was to have the work done: 1. By the parser 2. By the publisher 3. By the user Isn't that one of the "principles"? If not, I think it should be. Consider it as: 1. ~10 hour's work by the parser author, now (sorry, Mr Kaply!) 2. ~10,000,000 hours work by publishers, for ever 3. ~100,000,000 hours work by users, for ever Joking aside, do any parser authors have a view? -- Andy Mabbett Welcome to the world's longest week! From tantek at cs.stanford.edu Fri Mar 23 07:12:40 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Fri Mar 23 07:12:41 2007 Subject: burden of proof (was Re: [uf-dev] Suggested new parsing rule for alt text) In-Reply-To: <2wDnlMOqr8AGFwHk@pigsonthewing.org.uk> Message-ID: On 3/23/07 5:41 AM, "Andy Mabbett" wrote: >> the more complexity we layer into these parsing >> rules for very little benefit, the more bugs, errors, problems we >> introduce. > > Your "very little benefit" is hypothetical and unfounded. Andy, while I appreciate the swift calling of "hypothetical", you have the burden of proof backwards. The burden of proof is on any new parsing rules to demonstrate real world benefits using real world examples, not on Brian nor anyone else to "prove" very little benefit. That is, new proposals/rules have "very little benefit" (and potential cost), until proven otherwise (that they *have* a benefit, and *can be* implemented easily and interoperably). Thanks, Tantek From chris at placenamehere.com Fri Mar 23 07:20:52 2007 From: chris at placenamehere.com (Chris Casciano) Date: Fri Mar 23 07:21:26 2007 Subject: [uf-dev] hCard DoB -> calendar apps In-Reply-To: References: Message-ID: <02B99BEC-65AD-4A25-B8A8-CA7FEBEC91BB@placenamehere.com> On Mar 23, 2007, at 9:04 AM, Andy Mabbett wrote: > In message , > Scott > Reynen writes > >>>> Are there any hCard parsers, which will add a name/ DoB pair >>>> from an >>>> hCard, to a calendar application, as a recurring iCalendar event? > >> A third alternative would be to treat it as the responsibility (and >> authority) of the publisher, who could markup the birthday as a >> repeating event with hCalendar. > > I thought the order of priority was to have the work done: > > 1. By the parser > > 2. By the publisher > > 3. By the user > > Isn't that one of the "principles"? If not, I think it should be. > > Consider it as: > > 1. ~10 hour's work by the parser author, now (sorry, Mr Kaply!) > > 2. ~10,000,000 hours work by publishers, for ever > > 3. ~100,000,000 hours work by users, for ever > > Joking aside, do any parser authors have a view? not a parser author, but you left out my scenario: 0. By the application consuming the parsed data and. 0. ~0 hours of work for all involved because its a feature of existing consumers of the parsed data. Ultimately my feeling is that it could be a parser feature, wouldn't really harm anything, but from a publishers standpoint authoring birthdays everywhere as repeating events seems to be counter to the way one both thinks of a DOB as well as how a DOB would be typically published... though my expectation of how a DOB might be published on the web is quite limited [i'd almost think the opposite case of seeing a calendar entry and being able to extract a good vcard from it would happen more frequently] -- [ Chris Casciano ] [ chris@placenamehere.com ] [ http://placenamehere.com ] From andy at pigsonthewing.org.uk Fri Mar 23 07:25:24 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Fri Mar 23 07:37:26 2007 Subject: [uf-dev] Operator bug: not capturing "adr" without children Message-ID: Operator is not capturing ?adr? with no children (e.g. 45 High Street , Anytown. Test case: -- Andy Mabbett Welcome to the world's longest week! From andy at pigsonthewing.org.uk Fri Mar 23 07:54:15 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Fri Mar 23 09:10:53 2007 Subject: burden of proof (was Re: [uf-dev] Suggested new parsing rule for alt text) In-Reply-To: References: <2wDnlMOqr8AGFwHk@pigsonthewing.org.uk> Message-ID: In message , Tantek ?elik writes >> Your "very little benefit" is hypothetical and unfounded. > >Andy, while I appreciate the swift calling of "hypothetical", you have >the burden of proof backwards. > >The burden of proof is on any new parsing rules to demonstrate real >world benefits using real world examples, not on Brian nor anyone else >to "prove" very little benefit. > >That is, new proposals/rules have "very little benefit" (and potential >cost), until proven otherwise (that they *have* a benefit, I accept that. I thought my Wikipedia example provided such evidence - and my wider reference to CMSs a use case. > and *can be* implemented easily and interoperably). I don't accept that. I can't prove that something can be easily and interpretably implemented; surely it is for other people to show (if indeed it is the case) that it cannot. -- Andy Mabbett Welcome to the world's longest week! From tantek at cs.stanford.edu Fri Mar 23 09:24:05 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Fri Mar 23 09:24:06 2007 Subject: burden of proof (was Re: [uf-dev] Suggested new parsing rule for alt text) In-Reply-To: Message-ID: On 3/23/07 8:54 AM, "Andy Mabbett" wrote: > In message , Tantek ?elik > writes > >>> Your "very little benefit" is hypothetical and unfounded. >> >> Andy, while I appreciate the swift calling of "hypothetical", you have >> the burden of proof backwards. >> >> The burden of proof is on any new parsing rules to demonstrate real >> world benefits using real world examples, not on Brian nor anyone else >> to "prove" very little benefit. >> >> That is, new proposals/rules have "very little benefit" (and potential >> cost), until proven otherwise (that they *have* a benefit, > > I accept that. I thought my Wikipedia example provided such evidence - > and my wider reference to CMSs a use case. > >> and *can be* implemented easily and interoperably). > > I don't accept that. I can't prove that something can be easily and > interpretably implemented; Your not being able to prove it is insufficient reason to not accept the burden of proof. Rather, don't assume that you personally have to prove the proposal as such, but ask for help. Make it clear that you don't know if it can be easily/interoperably implemented, and ask the dev list for help. But accept that until it is proven as such, there must be doubt, and note that in your proposal. It is plenty fine to have proposals being considered with the doubts being explicitly noted. In fact, it is *preferable* if those making proposals are up front about about the doubts in their own proposals. It shows better introspection. > surely it is for other people to show (if > indeed it is the case) that it cannot. Similar to the burden of proof explanation above, it is not others' responsibility to prove a negative. The assumption is that something is hard to implement and non-interoperable until proven otherwise by someone actually easily building an implementation, and someone else building another implementation that interoperates with the first. Tantek From ryan at technorati.com Fri Mar 23 09:48:43 2007 From: ryan at technorati.com (Ryan King) Date: Fri Mar 23 09:48:48 2007 Subject: [uf-dev] hCard DoB -> calendar apps In-Reply-To: References: Message-ID: <15389755-3529-4CC2-AF71-91213B2C60C2@technorati.com> On Mar 22, 2007, at 4:28 PM, Scott Reynen wrote: > On Mar 22, 2007, at 5:56 PM, Chris Casciano wrote: >> On Mar 22, 2007, at 1:14 PM, Andy Mabbett wrote: >> >>> Are there any hCard parsers, which will add a name/ DoB pair from an >>> hCard, to a calendar application, as a recurring iCalendar event? >>> >>> Is this something Operator might do? >>> >>> Other fields, such as "adr", might be added as a "note". >> >> Is this the domain of the hcard parser, or the consumer of the >> extracted data? >> >> My first reaction would be the later. >> >> [For example, one can set birthdays on contacts in Apple's Address >> Book to automatically display in iCal] > > A third alternative would be to treat it as the responsibility (and > authority) of the publisher, who could markup the birthday as a > repeating event with hCalendar. You could do that, but it'd be tricky, esp. since RRULE is not yet and may never be specified in hCalendar (it's very hard to get right). RDATE would be the other option, but would require explicitly listing each date. -ryan -- Ryan King ryan@technorati.com From ryan at technorati.com Fri Mar 23 09:50:12 2007 From: ryan at technorati.com (Ryan King) Date: Fri Mar 23 09:50:16 2007 Subject: [uf-dev] Operator bug: not capturing "adr" without children In-Reply-To: References: Message-ID: <5A375E70-9536-429F-B346-96BE3AA9D532@technorati.com> On Mar 23, 2007, at 8:25 AM, Andy Mabbett wrote: > > Operator is not capturing ?adr? with no children (e.g. class=?adr?>45 High Street , Anytown. > > > Test case: ADR needs to have children (per vCard section 3.2.1), it can't be just a text value. -ryan -- Ryan King ryan@technorati.com From ianb at colorstudy.com Fri Mar 23 17:16:47 2007 From: ianb at colorstudy.com (Ian Bicking) Date: Fri Mar 23 17:17:16 2007 Subject: [uf-dev] hReview, rating, and best/worse Message-ID: <46047BFF.4060101@colorstudy.com> I'm working on parsing hReview (temporarily in http://svn.colorstudy.com/home/ianb/hReviewParser/trunk if anyone is curious -- haven't committed much yet though). The hReview spec says: """rating:: The rating is a fixed point integer (one decimal point of precision) from 1.0 to 5.0 inclusive indicating a rating for the item, higher indicating a better rating by default. Optionally a different integral "worst" value and/or "best" value MAY be specified to indicate a different range (e.g. 6 from 0-10). The "best" value may be numerically smaller than the "worst" value.""" But... that's not very clear. What does that actually look like? There's no examples that use that. 5 ? -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org | Write code, do good | http://topp.openplans.org/careers From paul_wilkins at xtra.co.nz Fri Mar 23 18:23:22 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Fri Mar 23 18:23:28 2007 Subject: [uf-dev] hReview, rating, and best/worse In-Reply-To: <46047BFF.4060101@colorstudy.com> References: <46047BFF.4060101@colorstudy.com> Message-ID: <46048B9A.1090401@xtra.co.nz> Ian Bicking wrote: > """rating:: The rating is a fixed point integer (one decimal point of > precision) from 1.0 to 5.0 inclusive indicating a rating for the item, > higher indicating a better rating by default. Optionally a different > integral "worst" value and/or "best" value MAY be specified to indicate > a different range (e.g. 6 from 0-10). The "best" value may be > numerically smaller than the "worst" value.""" > > But... that's not very clear. What does that actually look like? > There's no examples that use that. 5 ? http://www.xfront.com/microformats/hReview.html The Phantom Gourmet rates the restaurant as follows:
  • Food: 9/10
  • Service: 6/10
  • Ambience: 9.5/10
Another example, from the top of my head is:

Scoring from 33 to 100, you scored a total of 42.

-- Paul Wilkins From tantek at cs.stanford.edu Fri Mar 23 19:52:26 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Fri Mar 23 19:52:24 2007 Subject: [uf-dev] hReview, rating, and best/worse In-Reply-To: <46047BFF.4060101@colorstudy.com> Message-ID: On 3/23/07 6:16 PM, "Ian Bicking" wrote: > But... that's not very clear. What does that actually look like? > There's no examples that use that. >From the spec: http://microformats.org/wiki/hreview#Multidimensional_Restaurant_Review ... Food: 18/30; Ambience: 19/30; Service: 15/30; Price: $$... ... ... Note the 30 inside the
  • Tantek From ianb at colorstudy.com Fri Mar 23 20:20:25 2007 From: ianb at colorstudy.com (Ian Bicking) Date: Fri Mar 23 20:20:28 2007 Subject: [uf-dev] hReview examples for tests Message-ID: <4604A709.6000104@colorstudy.com> Does anyone have a examples of hReview documents to test a parser against? I'm interested in both valid and invalid examples. Or whatever anyone has. (It occurs to me that it would be kind of nice to have some normalized format for hReview documents, and then if your parser can serialize into that format then different code bases could share a set of tests.) -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org | Write code, do good | http://topp.openplans.org/careers From brian.suda at gmail.com Sat Mar 24 11:07:46 2007 From: brian.suda at gmail.com (Brian Suda) Date: Sat Mar 24 11:07:50 2007 Subject: [uf-dev] hReview examples for tests In-Reply-To: <4604A709.6000104@colorstudy.com> References: <4604A709.6000104@colorstudy.com> Message-ID: <21e770780703241207r39332033k8fef360cee446b93@mail.gmail.com> On 3/24/07, Ian Bicking wrote: > Does anyone have a examples of hReview documents to test a parser > against? I'm interested in both valid and invalid examples. Or > whatever anyone has. > > (It occurs to me that it would be kind of nice to have some normalized > format for hReview documents, and then if your parser can serialize into > that format then different code bases could share a set of tests.) --- for the GRDDL Primer i have been working on an RDF representation of review data. It is not completely, but you can look at the XSLT here: http://suda.co.uk/projects/microformats/hreview/hreview2rdfxml.xsl -brian -- brian suda http://suda.co.uk From hober0 at gmail.com Sat Mar 24 11:31:08 2007 From: hober0 at gmail.com (Edward O'Connor) Date: Sat Mar 24 11:45:11 2007 Subject: [uf-dev] Re: hReview examples for tests References: <4604A709.6000104@colorstudy.com> Message-ID: <86648qsakj.fsf@rakim.cfhp.org> > Does anyone have a examples of hReview documents to test a parser > against? I'm interested in both valid and invalid examples. Or > whatever anyone has. Here are a few (hopefully) valid examples: http://edward.oconnor.cx/2006/08/cask-room http://edward.oconnor.cx/2006/10/lud-in-the-mist http://edward.oconnor.cx/2006/11/hoboken http://edward.oconnor.cx/2006/11/basic http://edward.oconnor.cx/2006/11/legitimacy http://edward.oconnor.cx/2006/11/pizza-port http://edward.oconnor.cx/2006/12/lady-dottie-and-the-diamonds -- Edward O'Connor hober0@gmail.com Ense petit placidam sub libertate quietem. From brian.suda at gmail.com Sat Mar 24 11:50:25 2007 From: brian.suda at gmail.com (Brian Suda) Date: Sat Mar 24 11:50:27 2007 Subject: [uf-dev] Re: hReview examples for tests In-Reply-To: <86648qsakj.fsf@rakim.cfhp.org> References: <4604A709.6000104@colorstudy.com> <86648qsakj.fsf@rakim.cfhp.org> Message-ID: <21e770780703241250h5abc4158q919356dc0740207a@mail.gmail.com> > Does anyone have a examples of hReview documents to test a parser > against? I'm interested in both valid and invalid examples. Or > whatever anyone has. http://corkd.com/ has hReviews through-out. -brian -- brian suda http://suda.co.uk From robertc at gmail.com Sat Mar 24 12:50:52 2007 From: robertc at gmail.com (Rob Crowther) Date: Sat Mar 24 12:50:55 2007 Subject: [uf-dev] hReview examples for tests In-Reply-To: <4604A709.6000104@colorstudy.com> References: <4604A709.6000104@colorstudy.com> Message-ID: <3ce2ebd20703241350o49a54511uff28ef6648001313@mail.gmail.com> On 24/03/07, Ian Bicking wrote: > Does anyone have a examples of hReview documents to test a parser > against? I'm interested in both valid and invalid examples. Or > whatever anyone has. > I've done several on my blog, I think they're valid (all showed up in Tails and Operator last time I checked): http://www.boogdesign.com/b2evo/ There are currently five (three in one post, two others with one review each) on the front page and some more on the second page. Rob From chris at ozmm.org Sat Mar 24 13:27:54 2007 From: chris at ozmm.org (Chris Wanstrath) Date: Sat Mar 24 13:27:59 2007 Subject: [uf-dev] hReview examples for tests In-Reply-To: <4604A709.6000104@colorstudy.com> References: <4604A709.6000104@colorstudy.com> Message-ID: <8b73aaca0703241427s7b8cce4dse84c37474d05eafd@mail.gmail.com> On 3/23/07, Ian Bicking wrote: > Does anyone have a examples of hReview documents to test a parser > against? I'm interested in both valid and invalid examples. Or > whatever anyone has. Yes. http://hg.microformats.org/tests?mf=ef0bb5ab3db4;path=/hreview/;style=gitweb -- Chris Wanstrath http://errtheblog.com From alex at hopmann.org Sat Mar 24 14:24:15 2007 From: alex at hopmann.org (Alex Hopmann) Date: Sat Mar 24 14:24:23 2007 Subject: [uf-dev] Re: hReview examples for tests In-Reply-To: <21e770780703241250h5abc4158q919356dc0740207a@mail.gmail.com> References: <4604A709.6000104@colorstudy.com> <86648qsakj.fsf@rakim.cfhp.org> <21e770780703241250h5abc4158q919356dc0740207a@mail.gmail.com> Message-ID: <000f01c76e63$2974b300$8b01a8c0@alexhopdell83> > Does anyone have a examples of hReview documents to test a parser > against? I'm interested in both valid and invalid examples. Or > whatever anyone has. http://www.judysbook.com/ has hReviews all over. I can't promise that they are correct- let me know if you hit an issue with them. Alex Hopmann Launch21 LLC http://www.launch21.com From tantek at cs.stanford.edu Sat Mar 24 15:35:06 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Sat Mar 24 15:35:04 2007 Subject: [uf-dev] hReview examples for tests In-Reply-To: <8b73aaca0703241427s7b8cce4dse84c37474d05eafd@mail.gmail.com> Message-ID: On 3/24/07 2:27 PM, "Chris Wanstrath" wrote: > On 3/23/07, Ian Bicking wrote: > >> Does anyone have a examples of hReview documents to test a parser >> against? I'm interested in both valid and invalid examples. Or >> whatever anyone has. (replies removed) Rather than sending in email, please add hReview examples to: http://microformats.org/wiki/hreview-examples-in-wild And then reference that URL when requests for examples are made. Question added to hReview FAQ. http://microformats.org/wiki/hreview-faq Thanks, Tantek From andy at pigsonthewing.org.uk Fri Mar 23 09:58:44 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Mar 25 11:28:14 2007 Subject: burden of proof (was Re: [uf-dev] Suggested new parsing rule for alt text) In-Reply-To: References: Message-ID: In message , Tantek ?elik writes >On 3/23/07 8:54 AM, "Andy Mabbett" wrote: >>> That is, new proposals/rules have "very little benefit" (and potential >>> cost), until proven otherwise (that they *have* a benefit, >> >> I accept that. I thought my Wikipedia example provided such evidence - >> and my wider reference to CMSs a use case. >> >>> and *can be* implemented easily and interoperably). >> >> I don't accept that. I can't prove that something can be easily and >> interoperably implemented; > >Your not being able to prove it is insufficient reason to not accept the >burden of proof. I wasn't preferring to personal inability, but to logical impossibility. >Rather, don't assume that you personally have to prove the proposal as such, >but ask for help. I did. I asked: Can anyone foresee any problems with that? >> surely it is for other people to show (if >> indeed it is the case) that it cannot. > >Similar to the burden of proof explanation above, it is not others' >responsibility to prove a negative. Nobody is asking them to prove a negative; quite the reverse. > The assumption is that something is >hard to implement and non-interoperable until proven otherwise by someone >actually easily building an implementation, and someone else building >another implementation that interoperates with the first. We can never prove complete interoperability; we can only find cases failure to work interoperably. -- Andy Mabbett Welcome to the world's longest week! From andy at pigsonthewing.org.uk Fri Mar 23 10:16:22 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Mar 25 11:28:15 2007 Subject: [uf-dev] Operator bug: not capturing "adr" without children In-Reply-To: <5A375E70-9536-429F-B346-96BE3AA9D532@technorati.com> References: <5A375E70-9536-429F-B346-96BE3AA9D532@technorati.com> Message-ID: In message <5A375E70-9536-429F-B346-96BE3AA9D532@technorati.com>, Ryan King writes >On Mar 23, 2007, at 8:25 AM, Andy Mabbett wrote: > >> >> Operator is not capturing ?adr? with no children (e.g. >class=?adr?>45 High Street , Anytown. >> >> >> Test case: > >ADR needs to have children (per vCard section 3.2.1), it can't be just >a text value. Then the cheatsheets (hCard and adr; 'wiki' and PDF) needs to be changed to reflect that. I'm not sure how, though. -- Andy Mabbett Welcome to the world's longest week! From andy at pigsonthewing.org.uk Fri Mar 23 10:43:39 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Mar 25 11:28:15 2007 Subject: [uf-dev] Operator bug: not capturing "adr" without children In-Reply-To: <5A375E70-9536-429F-B346-96BE3AA9D532@technorati.com> References: <5A375E70-9536-429F-B346-96BE3AA9D532@technorati.com> Message-ID: In message <5A375E70-9536-429F-B346-96BE3AA9D532@technorati.com>, Ryan King writes >ADR needs to have children (per vCard section 3.2.1), it can't be just >a text value. I've now read that, and can't see anything which mandates this; though I can see that, logically, there is a need to populate at least one vcard-adr component. How do we deal with data (perhaps legacy) which has an undivided address field? Again, Wikipedia provides plenty of examples, where a "headquarters" address (for a business, for example) may contain a full or partial postal address, or just a city/county or city/country pair: Or where the granularity of the "location" or "place" field is undefined? "Place" ("locale" in the template) is a street "Place" is a local district "Place" is a city Perhaps we should (on the basis of being strict in what we send, and generous in what we receive) elect a default field, probably one of: street-address extended-address region locality ? The second of those would my initial choice. -- Andy Mabbett Welcome to the world's longest week! From tantek at cs.stanford.edu Sun Mar 25 12:33:08 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Sun Mar 25 12:33:06 2007 Subject: burden of proof (was Re: [uf-dev] Suggested new parsing rule for alt text) In-Reply-To: Message-ID: On 3/23/07 10:58 AM, "Andy Mabbett" wrote: > In message , Tantek ?elik > writes > >> On 3/23/07 8:54 AM, "Andy Mabbett" wrote: > >>>> That is, new proposals/rules have "very little benefit" (and potential >>>> cost), until proven otherwise (that they *have* a benefit, >>> >>> I accept that. I thought my Wikipedia example provided such evidence - >>> and my wider reference to CMSs a use case. >>> >>>> and *can be* implemented easily and interoperably). >>> >>> I don't accept that. I can't prove that something can be easily and >>> interoperably implemented; >> >> Your not being able to prove it is insufficient reason to not accept the >> burden of proof. > > I wasn't preferring to personal inability, but to logical impossibility. In that case let's take the aspects one at a time. 1. Easily implementable. This can be proven by implementing, easily. That sounds like a tautology, but it literally means that. Build it, and note how hard it was. If it was easy then proof has been completed. 2. Interoperably. This is much more difficult as you allude. Further discussed below. >> Rather, don't assume that you personally have to prove the proposal as such, >> but ask for help. > > I did. I asked: > > Can anyone foresee any problems with that? Let me clarify, ask for help with demonstrating the implementability which could prove (1), rather than or in addition to help with raising problems/issues (though that can be helpful as well if such problems/issues are based on real world examples). >> The assumption is that something is >> hard to implement and non-interoperable until proven otherwise by someone >> actually easily building an implementation, and someone else building >> another implementation that interoperates with the first. > > We can never prove complete interoperability; we can only find cases > failure to work interoperably. Strictly speaking you are correct - it isn't possible to "prove" complete interoperability, all you can do is find and fix failure cases. It *is* possible to demonstrate some level of "reasonable" or "acceptable" interoperability through the use of some number of test cases. But even that is not what I intended to ask for here. "proving" interoperability is too strong of a request, and test suites, though strongly desirable (and I am strong proponent thereof), are also more than I intended to request in this thread. "Demonstrate some amount of" interoperability is more reasonable, especially if common real world content cases are used to demonstrate the interoperability. I hope this clarification is useful. I have attempted to capture some of these thoughts around burden of proof and brainstorming/proposals/suggestions here to continue building our shared community understanding: http://microformats.org/wiki/brainstorming Thanks, Tantek From ryan at technorati.com Sun Mar 25 17:11:19 2007 From: ryan at technorati.com (Ryan King) Date: Sun Mar 25 17:11:23 2007 Subject: [uf-dev] Re: [uf-discuss] http://microformats.org/wiki/hcard-issues in adr: singular or plural? In-Reply-To: <6UFkM1l3ZCBGFwsl@pigsonthewing.org.uk> References: <21e770780703230815r5aef74cei1fbe76fb803c4cf5@mail.gmail.com> <6UFkM1l3ZCBGFwsl@pigsonthewing.org.uk> Message-ID: <06331621-1769-4E7F-B090-05C99EAC4FC4@technorati.com> (moving to -dev) On Mar 23, 2007, at 12:11 PM, Andy Mabbett wrote: > In message > <21e770780703230815r5aef74cei1fbe76fb803c4cf5@mail.gmail.com>, > Brian Suda writes > >> All the elements for an ADR appear to be zero or more. >> >> If you have multiple street-addresses on a page they will be >> concatenated together with a ',' and used as a single element in the >> ADR. > > That may work for street-address, but it won't work for postcode or > post-office-box (in at least some territories, the comma would > invalidate both). > > Are there any country-names where a comma is used? > > I seem to recall Operator barfing, when I used two locality > attributes, previously. This is a non-issue. The comma can be escaped with a backslash. -ryan -- Ryan King ryan@technorati.com From ianb at colorstudy.com Sun Mar 25 17:15:41 2007 From: ianb at colorstudy.com (Ian Bicking) Date: Sun Mar 25 17:15:44 2007 Subject: [uf-dev] hReview examples for tests In-Reply-To: <8b73aaca0703241427s7b8cce4dse84c37474d05eafd@mail.gmail.com> References: <4604A709.6000104@colorstudy.com> <8b73aaca0703241427s7b8cce4dse84c37474d05eafd@mail.gmail.com> Message-ID: <46071EBD.8080905@colorstudy.com> Chris Wanstrath wrote: > On 3/23/07, Ian Bicking wrote: > >> Does anyone have a examples of hReview documents to test a parser >> against? I'm interested in both valid and invalid examples. Or >> whatever anyone has. > > Yes. > > http://hg.microformats.org/tests?mf=ef0bb5ab3db4;path=/hreview/;style=gitweb Thanks Chris, this is exactly the sort of thing I was looking for. (Examples in the wild, as Tantek referred to, are kind of useful, but they don't make for good unit tests.) I might also try the examples in the wild too, inspect them manually, and then if something seems wrong try to extract that into a smaller and more repeatable test. -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org | Write code, do good | http://topp.openplans.org/careers From mdagn at spraci.com Sun Mar 25 19:52:06 2007 From: mdagn at spraci.com (Michael MD) Date: Sun Mar 25 19:52:14 2007 Subject: [uf-dev] Re: [uf-discuss] http://microformats.org/wiki/hcard-issuesin adr: singular or plural? References: <21e770780703230815r5aef74cei1fbe76fb803c4cf5@mail.gmail.com><6UFkM1l3ZCBGFwsl@pigsonthewing.org.uk> <06331621-1769-4E7F-B090-05C99EAC4FC4@technorati.com> Message-ID: <001b01c76f5a$22e7e0f0$116bacca@COMCEN> >> >> Are there any country-names where a comma is used? >> >> I seem to recall Operator barfing, when I used two locality attributes, >> previously. > > This is a non-issue. The comma can be escaped with a backslash. In the parser I'm working on such things would be returned as arrays Is it ok to do this or is concatenating to a single string a requirement in the parser? (then it would be up to the app to decide what to do with them .. but at least the data is still there...) I thought that might be one of those things that probably should be left up to the application rather than the parser itself. From paul_wilkins at xtra.co.nz Sun Mar 25 20:01:00 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Sun Mar 25 20:01:09 2007 Subject: [uf-dev] Re: [uf-discuss]http://microformats.org/wiki/hcard-issuesin adr: singular or plural? References: <21e770780703230815r5aef74cei1fbe76fb803c4cf5@mail.gmail.com><6UFkM1l3ZCBGFwsl@pigsonthewing.org.uk><06331621-1769-4E7F-B090-05C99EAC4FC4@technorati.com> <001b01c76f5a$22e7e0f0$116bacca@COMCEN> Message-ID: <007201c76f5b$5dc531e0$bc08a8c0@nzto22> From: "Michael MD" > In the parser I'm working on such things would be returned as arrays > > Is it ok to do this or is concatenating to a single string a requirement > in the parser? > (then it would be up to the app to decide what to do with them .. but at > least the data is still there...) > > I thought that might be one of those things that probably should be left > up to the application rather than the parser itself. We're going to have to come up with some kind of accepted standard for this, otherwise we're going to have parsers returning results in a number of different ways, which will cause difficulties when integrating with other tools. For example, both Operator and X2V perform both parsing and converting. Is there information available about a common standardised array or object format for microformats? -- Paul Wilkins From paul_wilkins at xtra.co.nz Sun Mar 25 20:25:00 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Sun Mar 25 20:25:08 2007 Subject: [uf-dev] Re: [uf-discuss]http://microformats.org/wiki/hcard-issuesin adr: singular or plural? References: <21e770780703230815r5aef74cei1fbe76fb803c4cf5@mail.gmail.com><6UFkM1l3ZCBGFwsl@pigsonthewing.org.uk><06331621-1769-4E7F-B090-05C99EAC4FC4@technorati.com> <001b01c76f5a$22e7e0f0$116bacca@COMCEN> Message-ID: <007f01c76f5e$b7e62230$bc08a8c0@nzto22> From: "Michael MD" > In the parser I'm working on such things would be returned as arrays Existing array practices are well accepted. As an example, PHP microformat helpers are available at http://codeigniter.com/wiki/microformats/ Their array structure is an example of microformat arrays. I disagree though with their array naming conventions. The keys should be named the same as microformat names used to identify them. Edge cases which involve multiple values may be best stored as an array structure, for example, with the extended-address value. . . . 'extended-address' => array ( 'Corner of Pilsbury and Dough Streets', 'Cashel Plaza' ), . . . -- Paul Wilkins From ryan at technorati.com Sun Mar 25 22:48:47 2007 From: ryan at technorati.com (Ryan King) Date: Sun Mar 25 22:48:51 2007 Subject: [uf-dev] Re: [uf-discuss] http://microformats.org/wiki/hcard-issuesin adr: singular or plural? In-Reply-To: <001b01c76f5a$22e7e0f0$116bacca@COMCEN> References: <21e770780703230815r5aef74cei1fbe76fb803c4cf5@mail.gmail.com><6UFkM1l3ZCBGFwsl@pigsonthewing.org.uk> <06331621-1769-4E7F-B090-05C99EAC4FC4@technorati.com> <001b01c76f5a$22e7e0f0$116bacca@COMCEN> Message-ID: <4FE84371-0606-4802-A43A-6CCC43D3C7E8@technorati.com> On Mar 25, 2007, at 8:52 PM, Michael MD wrote: >>> >>> Are there any country-names where a comma is used? >>> >>> I seem to recall Operator barfing, when I used two locality >>> attributes, previously. >> >> This is a non-issue. The comma can be escaped with a backslash. > > In the parser I'm working on such things would be returned as arrays > > Is it ok to do this or is concatenating to a single string a > requirement in the parser? > (then it would be up to the app to decide what to do with them .. > but at least the data is still there...) If your parser doesn't do vCard conversion, the particual issue of commas in field values doesn't apply. It's only the vCard serialization where the comma matters (and is easily escapable with a backslash). -ryan -- Ryan King ryan@technorati.com From andy at pigsonthewing.org.uk Mon Mar 26 02:45:54 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Mar 26 02:57:56 2007 Subject: [uf-dev] Moving between lists (Was: http://microformats.org/wiki/hcard-issues in adr: singular or plural?) In-Reply-To: <06331621-1769-4E7F-B090-05C99EAC4FC4@technorati.com> References: <21e770780703230815r5aef74cei1fbe76fb803c4cf5@mail.gmail.com> <6UFkM1l3ZCBGFwsl@pigsonthewing.org.uk> <06331621-1769-4E7F-B090-05C99EAC4FC4@technorati.com> Message-ID: In message <06331621-1769-4E7F-B090-05C99EAC4FC4@technorati.com>, Ryan King writes >(moving to -dev) When moving between lists, please remove the tags, such as: [uf-dev] and [uf-discuss] from the subject line; I (and, I'm sure, many other people) sort mail into folders, based on those tags. Thank you. -- Andy Mabbett From paul_wilkins at xtra.co.nz Mon Mar 26 03:12:28 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Mon Mar 26 03:12:34 2007 Subject: [uf-dev] Moving between lists (Was: http://microformats.org/wiki/hcard-issues in adr: singular or plural?) In-Reply-To: References: <21e770780703230815r5aef74cei1fbe76fb803c4cf5@mail.gmail.com> <6UFkM1l3ZCBGFwsl@pigsonthewing.org.uk> <06331621-1769-4E7F-B090-05C99EAC4FC4@technorati.com> Message-ID: <4607AA9C.5000003@xtra.co.nz> Andy Mabbett wrote: >When moving between lists, please remove the tags, such as: > > [uf-dev] >and > [uf-discuss] > >from the subject line; I (and, I'm sure, many other people) sort mail >into folders, based on those tags. > > You may want to consider filtering based on the To address field instead. That way user error (which is out of your hands) won't affect you so badly. -- Paul Wilkins From andy at pigsonthewing.org.uk Wed Mar 28 01:57:01 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Mar 28 02:06:36 2007 Subject: [uf-dev] Wanted: On-line parser for Geo Message-ID: Are there any on-line parsers for Geo? Life Lint: is AWOL, and the Almost-universal parser: doesn't help in this case. -- Andy Mabbett From brian.suda at gmail.com Wed Mar 28 02:49:54 2007 From: brian.suda at gmail.com (Brian Suda) Date: Wed Mar 28 02:49:57 2007 Subject: [uf-dev] Wanted: On-line parser for Geo In-Reply-To: References: Message-ID: <21e770780703280349w69eb0a00u478671e5e863c4cd@mail.gmail.com> On 3/28/07, Andy Mabbett wrote: > > Are there any on-line parsers for Geo? if you have a look on the GEO wiki page, there is a list of implementations[1]. -brian [1] - http://microformats.org/wiki/geo#Implementations -- brian suda http://suda.co.uk From andy at pigsonthewing.org.uk Wed Mar 28 03:23:23 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Mar 28 03:42:21 2007 Subject: [uf-dev] Wanted: On-line parser for Geo In-Reply-To: <21e770780703280349w69eb0a00u478671e5e863c4cd@mail.gmail.com> References: <21e770780703280349w69eb0a00u478671e5e863c4cd@mail.gmail.com> Message-ID: In message <21e770780703280349w69eb0a00u478671e5e863c4cd@mail.gmail.com>, Brian Suda writes >> Are there any on-line parsers for Geo? > >if you have a look on the GEO wiki page, there is a list of implementations[1]. >[1] - http://microformats.org/wiki/geo#Implementations Thank you; I looked at that, and found none, before asking here. -- Andy Mabbett From brian.suda at gmail.com Wed Mar 28 03:58:07 2007 From: brian.suda at gmail.com (Brian Suda) Date: Wed Mar 28 03:58:11 2007 Subject: [uf-dev] Wanted: On-line parser for Geo In-Reply-To: References: <21e770780703280349w69eb0a00u478671e5e863c4cd@mail.gmail.com> Message-ID: <21e770780703280458n1af169a6p69a3ab2c0d12d7a2@mail.gmail.com> On 3/28/07, Andy Mabbett wrote: > In message > <21e770780703280349w69eb0a00u478671e5e863c4cd@mail.gmail.com>, Brian > Suda writes > > >> Are there any on-line parsers for Geo? > > > >if you have a look on the GEO wiki page, there is a list of implementations[1]. > > >[1] - http://microformats.org/wiki/geo#Implementations > > Thank you; I looked at that, and found none, before asking here. http://suda.co.uk/projects/microformats/geo/ is on the list on the wiki and seems to work just fine for me. What exactly do you MEAN when you say parser? that service will parse the HTML into KML and GeoRSS formats - what sort of output are you looking for? JSON, XML, serialized PHP, other? Also, if you find services that are no longer online, please note this on the wiki so others don't have the same problems later. thanks, -brian -- brian suda http://suda.co.uk From andy at pigsonthewing.org.uk Wed Mar 28 09:59:04 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Mar 28 10:04:17 2007 Subject: [uf-dev] Wanted: On-line parser for Geo In-Reply-To: <21e770780703280458n1af169a6p69a3ab2c0d12d7a2@mail.gmail.com> References: <21e770780703280349w69eb0a00u478671e5e863c4cd@mail.gmail.com> <21e770780703280458n1af169a6p69a3ab2c0d12d7a2@mail.gmail.com> Message-ID: <4EhkIUHozqCGFw0F@pigsonthewing.org.uk> In message <21e770780703280458n1af169a6p69a3ab2c0d12d7a2@mail.gmail.com>, Brian Suda writes >On 3/28/07, Andy Mabbett wrote: >> In message >> <21e770780703280349w69eb0a00u478671e5e863c4cd@mail.gmail.com>, Brian >> Suda writes >> >> >> Are there any on-line parsers for Geo? >> > >> >if you have a look on the GEO wiki page, there is a list of implementations[1]. >> >> >[1] - http://microformats.org/wiki/geo#Implementations >> >> Thank you; I looked at that, and found none, before asking here. > > >http://suda.co.uk/projects/microformats/geo/ is on the list on the >wiki and seems to work just fine for me. That page says: "Brian Suda has written some geo extracting code" which I read to mean that there was code available at the linked URL, available for other developers could include in their projects. If I made that mistake then I think others, with less knowledge of HTML or microformats, are even more likely to do so. Perhaps you'd like to change the wording, to something more meaningful to lay readers? > that service will parse the HTML into KML and GeoRSS >formats - what sort of output are you looking for? JSON, XML, >serialized PHP, other? HTML - as a minimum, something like the Almost-Universal parser. Ideally, something which will return a list of the Geo microformatted co-ordinates on the page, linking each to, say, Google maps or some other mapping service [1] - rather like an on-page version of the Operator drop-down. That would be a useful resource, not only for day to day use, but also least for including in tutorials and the like ("this page has/ your page should now have a Geo microformat for the Taj Mahal, as you can see if you enter it's URL at X") where the reader may well have not yet installed an in-browser parser such as Operator. >Also, if you find services that are no longer online, please note this >on the wiki so others don't have the same problems later. If you refer to LifeLint, I reported its absence on the mailing list, on 23 December last: Nobody responded; so I commented-out its 'wiki' entry on 3 January: [1] Perhaps to (example coordinates included): which links to many others. -- Andy Mabbett From ryan at technorati.com Wed Mar 28 14:44:41 2007 From: ryan at technorati.com (Ryan King) Date: Wed Mar 28 14:44:48 2007 Subject: [uf-dev] hcalendar rrule test in repo Message-ID: I added a test awhile back for RRULE in hcalendar[1]. Given that non one (AFAICT) has implemented it, I'm going to remove it unless I here any objections. -ryan 1. http://hg.microformats.org/tests? cmd=changeset;node=c7b7774e635d;style=gitweb -- Ryan King ryan@technorati.com From ryan at technorati.com Wed Mar 28 15:05:20 2007 From: ryan at technorati.com (Ryan King) Date: Wed Mar 28 15:05:26 2007 Subject: [uf-dev] test suite usage Message-ID: <1B600545-A9A5-4FFC-BEBC-80F4B50DFD96@technorati.com> So, who's using the test suite? If you're building a parser buy not using it, why? What could we do to help? -ryan -- Ryan King ryan@technorati.com From mdagn at spraci.com Wed Mar 28 17:39:24 2007 From: mdagn at spraci.com (Michael MD) Date: Wed Mar 28 17:39:28 2007 Subject: [uf-dev] test suite usage References: <1B600545-A9A5-4FFC-BEBC-80F4B50DFD96@technorati.com> Message-ID: <001b01c771a3$15895c40$116bacca@COMCEN> > So, who's using the test suite? If you're building a parser buy not > using it, why? What could we do to help? > I'm starting to use it ... only just worked out how to use Mercurial to download it so I could test offline (the windows version baffled me... but hg -clone worked nicely in cygwin) ... The test suite is very helpful! From microformats at kaply.com Wed Mar 28 20:16:57 2007 From: microformats at kaply.com (Mike Kaply) Date: Wed Mar 28 20:17:01 2007 Subject: [uf-dev] test suite usage In-Reply-To: <1B600545-A9A5-4FFC-BEBC-80F4B50DFD96@technorati.com> References: <1B600545-A9A5-4FFC-BEBC-80F4B50DFD96@technorati.com> Message-ID: On 3/28/07, Ryan King wrote: > So, who's using the test suite? If you're building a parser buy not > using it, why? What could we do to help? I'm not using it because I don't want to download the whole thing and run it locally. I'd rather see it as a navigable set of tests on a web page (of course I'm biased because my stuff is browser based). I also wish the testcases actually showed the source of the testcase along side the HTML of the side case (and maybe even an iframe that integrated the output vcard/ics into the page as well) There should be one page to go to to see - testcase/source/result of test. Mike Kaply From chris at ozmm.org Wed Mar 28 22:01:29 2007 From: chris at ozmm.org (Chris Wanstrath) Date: Wed Mar 28 22:01:32 2007 Subject: [uf-dev] test suite usage In-Reply-To: <1B600545-A9A5-4FFC-BEBC-80F4B50DFD96@technorati.com> References: <1B600545-A9A5-4FFC-BEBC-80F4B50DFD96@technorati.com> Message-ID: <8b73aaca0703282301l2ac5c5f9xa2c6822676b6cb0c@mail.gmail.com> On 3/28/07, Ryan King wrote: > So, who's using the test suite? If you're building a parser buy not > using it, why? What could we do to help? I've slowly been poking at the tests with mofo. I've got a little runner I threw together in Ruby: http://pastie.caboo.se/50234 Still a lot of failures, but at least I have an idea of what needs improving. Thanks to JSON and vpim (Ruby library for parsing iCal and vCard), writing the actual test runner was trivial. I'll probably add Atom support to it soon then hopefully get it all passing (in time). Overall the tests get an A+. Little awkward using mercurial because I can't svn:external or piston, but it's no big deal. -- Chris Wanstrath http://errtheblog.com From ryan at technorati.com Thu Mar 29 10:45:04 2007 From: ryan at technorati.com (Ryan King) Date: Thu Mar 29 10:45:10 2007 Subject: [uf-dev] test suite usage In-Reply-To: <8b73aaca0703282301l2ac5c5f9xa2c6822676b6cb0c@mail.gmail.com> References: <1B600545-A9A5-4FFC-BEBC-80F4B50DFD96@technorati.com> <8b73aaca0703282301l2ac5c5f9xa2c6822676b6cb0c@mail.gmail.com> Message-ID: <8DB1D1D4-DC19-4609-9078-331BE6D5D5CE@technorati.com> On Mar 28, 2007, at 11:01 PM, Chris Wanstrath wrote: > On 3/28/07, Ryan King wrote: > >> So, who's using the test suite? If you're building a parser buy not >> using it, why? What could we do to help? > > I've slowly been poking at the tests with mofo. I've got a little > runner I threw together in Ruby: http://pastie.caboo.se/50234 > > Still a lot of failures, but at least I have an idea of what needs > improving. > > Thanks to JSON and vpim (Ruby library for parsing iCal and vCard), > writing the actual test runner was trivial. I'll probably add Atom > support to it soon then hopefully get it all passing (in time). > > Overall the tests get an A+. Little awkward using mercurial because I > can't svn:external or piston, but it's no big deal. For svn, we could use tailor to create an svn mirror of it. -ryan -- Ryan King ryan@technorati.com From ryan at technorati.com Thu Mar 29 10:47:17 2007 From: ryan at technorati.com (Ryan King) Date: Thu Mar 29 10:47:21 2007 Subject: [uf-dev] test suite usage In-Reply-To: <001b01c771a3$15895c40$116bacca@COMCEN> References: <1B600545-A9A5-4FFC-BEBC-80F4B50DFD96@technorati.com> <001b01c771a3$15895c40$116bacca@COMCEN> Message-ID: <64B43B72-0CFC-4727-8862-10AB9A8348F3@technorati.com> On Mar 28, 2007, at 6:39 PM, Michael MD wrote: >> So, who's using the test suite? If you're building a parser buy not >> using it, why? What could we do to help? >> > > I'm starting to use it ... only just worked out how to use > Mercurial to download it so I could test offline > (the windows version baffled me... but hg -clone worked nicely in > cygwin) ... > > The test suite is very helpful! Would it be useful if you could download them as a tarball or zip file? -ryan -- Ryan King ryan@technorati.com From paul_wilkins at xtra.co.nz Thu Mar 29 12:38:35 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Thu Mar 29 12:38:45 2007 Subject: [uf-dev] test suite usage In-Reply-To: References: <1B600545-A9A5-4FFC-BEBC-80F4B50DFD96@technorati.com> Message-ID: <460C23CB.80805@xtra.co.nz> Mike Kaply wrote: > I'm not using it because I don't want to download the whole thing and > run it locally. I'd rather see it as a navigable set of tests on a web > page (of course I'm biased because my stuff is browser based). > > I also wish the testcases actually showed the source of the testcase > along side the HTML of the side case That's a good idea. I've put together a simple navigator for the hCard test collection at http://phenix.rootshell.be/~pmw57/hcard/test/ > (and maybe even an iframe that > integrated the output vcard/ics into the page as well) > > There should be one page to go to to see - testcase/source/result of test. -- Paul Wilkins