From andy at pigsonthewing.org.uk Fri May 4 10:16:59 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Fri May 4 10:18:13 2007 Subject: [uf-dev] Reusing hCalendar events Message-ID: <4ulECxeLq2OGFw2a@pigsonthewing.org.uk> We need, I feel, an in-browser hCalendar parser which "collects" one or more events from a web page, remembers them, and allows the user to output them according to a number of pre- or user- defined templates, so that they can be easily reused. The creation of such templates, by users, should be made as simple as possible. Those templates might include wiki format, CSV, and (X)HTML code in the form used by the user's website, for inclusion in that website. By way of a model, consider the way Zotero: parses, saves and outputs COinS citations (and, incidentally, could do so for a citation microformat); or how the "CopyURL+" extension for FireFox does (or did) so for URLs and related text: This could be a new parser, or additional functionality in Operator. I'd be happy to expand on this and do testing, if someone fancies having a crack at coding it. -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From ryan at technorati.com Wed May 16 12:37:01 2007 From: ryan at technorati.com (Ryan King) Date: Wed May 16 12:37:05 2007 Subject: [uf-dev] hcalendar rrule test in repo In-Reply-To: References: Message-ID: <8DE1AF44-469C-43BE-877F-F44D02515239@technorati.com> On Mar 28, 2007, at 3:44 PM, Ryan King wrote: > 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. Ok, given that I've heard nothing about this (and it's been over a month), I'm going to delete this test. On a related note, I'm working on some improvements to the test suite based on experience and feedback from the last few months. Look for some mail messages about this soon. -ryan From connolly at w3.org Wed May 16 13:03:59 2007 From: connolly at w3.org (Dan Connolly) Date: Wed May 16 13:04:05 2007 Subject: [uf-dev] hcalendar rrule test in repo In-Reply-To: <8DE1AF44-469C-43BE-877F-F44D02515239@technorati.com> References: <8DE1AF44-469C-43BE-877F-F44D02515239@technorati.com> Message-ID: <1179345839.15441.44.camel@pav.dm93.org> On Wed, 2007-05-16 at 12:37 -0700, Ryan King wrote: > On Mar 28, 2007, at 3:44 PM, Ryan King wrote: > > > 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. > > Ok, given that I've heard nothing about this (and it's been over a > month), I'm going to delete this test. Hmm... sorry for the late reply, but I did implement rrule in glean-hcal.xsl http://www.w3.org/2002/12/cal/glean-hcal.xsl I don't seem to pass that particular test, though... http://hg.microformats.org/tests?cmd=file;file=hcalendar/14-calendar-anniversary.html;filenode=a2f860316eeddbe5ede16ad4898ff7c330e3a0f4;style=gitweb I don't handle category nor class, nor dates without the -'s in them. Support for "every tuesday at 1:30pm" style events is a requirement of my personal calendar setup. I seem to use floating times... 13:30 along with command-line hack later in my pipeline (--floattz=America/Chicago). I don't mind dropping the test for now, but I hope to get back to it in due course. This is still an open issue in the RDF Calendar work. http://www.w3.org/2002/12/cal/report1173#L21805 http://www.w3.org/TR/2005/NOTE-rdfcal-20050929/#L21805 -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ From ryan at technorati.com Wed May 16 14:34:46 2007 From: ryan at technorati.com (Ryan King) Date: Wed May 16 14:34:51 2007 Subject: [uf-dev] hcalendar rrule test in repo In-Reply-To: <1179345839.15441.44.camel@pav.dm93.org> References: <8DE1AF44-469C-43BE-877F-F44D02515239@technorati.com> <1179345839.15441.44.camel@pav.dm93.org> Message-ID: <5E0F71B3-957C-4C06-809F-99A2F7ED552A@technorati.com> On May 16, 2007, at 1:03 PM, Dan Connolly wrote: > I don't mind dropping the test for now, but I hope to get > back to it in due course. This is still an open issue in > the RDF Calendar work. > http://www.w3.org/2002/12/cal/report1173#L21805 > http://www.w3.org/TR/2005/NOTE-rdfcal-20050929/#L21805 I'd love to put it back in, once we can specify more clearly how it should be expressed in hCalendar. -ryan From ryan at technorati.com Wed May 16 17:03:53 2007 From: ryan at technorati.com (Ryan King) Date: Wed May 16 17:03:56 2007 Subject: [uf-dev] hatom test suite useage? Message-ID: <1599E21E-37BA-477C-A79F-E2639264A707@technorati.com> Is anyone else using the test suite for hAtom? (besides me and X2V) -ryan From bsittler at gmail.com Fri May 18 09:58:43 2007 From: bsittler at gmail.com (Ben Wiley Sittler) Date: Fri May 18 09:58:47 2007 Subject: [uf-dev] hatom test suite useage? In-Reply-To: <1599E21E-37BA-477C-A79F-E2639264A707@technorati.com> References: <1599E21E-37BA-477C-A79F-E2639264A707@technorati.com> Message-ID: On 5/16/07, Ryan King wrote: > Is anyone else using the test suite for hAtom? (besides me and X2V) awesome! i was previously unaware of this test suite, but i just tested it with rss panel x and it appears to handle all those cases correctly, except that it doesn't pick up the id attribute from the body element in the implicit hfeed cases when constructing the feed uri. perhaps i will fix that one of these days... rss panel x: http://zoehep.xent.com/~bsittler/rsspanel.html -ben p.s. despite the name, rss panel x reads not just rss feeds but also hatom, atom, opml, and a few of the non-rss rdf variants. From ryan at technorati.com Fri May 18 12:03:01 2007 From: ryan at technorati.com (Ryan King) Date: Fri May 18 12:03:03 2007 Subject: [uf-dev] hatom test suite useage? In-Reply-To: <1599E21E-37BA-477C-A79F-E2639264A707@technorati.com> References: <1599E21E-37BA-477C-A79F-E2639264A707@technorati.com> Message-ID: <9188C76B-20FF-480E-AE60-54ED749EA18A@technorati.com> On May 16, 2007, at 5:03 PM, Ryan King wrote: > Is anyone else using the test suite for hAtom? (besides me and X2V) Ok, I was mainly asking this because I'd like to do some major refactoring on the test suite. For a bit of context, several of us working on creating hCard and hCalendar test last year. Another group created an hAtom test suite. Those have since been merged into one [1]. Since that time I've learned quite a bit about how we can do things better. Specifically, I've read these documents: [2] [3] [4]. You should read those, too. So, to cut to the chase, here's my plans for our test suite, based on our experience: 1. organize tests into categories based on complexity CSS used abcdef (atomic, basic, composite, detailed, evil and failure)[5]. I'm not sure if we need a system that complex or detailed, but we definitely need to start with atomic tests and work up towards more complexity. My experience backs this up as well. I'm currently trying to get my hAtom parser compliant with the hAtom test suite, but all of the tests are what would probably be considered 'composite' or 'detailed' tests. That means I have to implemented a large part (if not all) of hAtom before I can get a single test to pass. This is not very good for morale. :D 2. Organize the tests in a canonical ordering, from simple to complex. I sort of did this with hCard and hCalendar, though I couldn't explain fully at the time why it worked. At the time, I just put them in the order that I was implementing them, which naturally went from simple to complex. 3. Make the tests more navigable. The major use case considered when building the suite was parsing code that could run automated tests. Since then, we've had things like Operator, where the testing is done by hand. We need to make that easier to do. For this I want to start with creating cover pages and navigation links, as described in [6] 4. Provide more documentation on the purpose of each test. [7] 5. Explicitly state the status of each test.[8] Some tests are still works in progress, but it's tough to know that if you aren't actively work on them. ---- Unless there's objections or better suggestions for these problems, I'm going to start implementing them for hAtom. If we like them for hAtom, we can backport them to hCard and hCalendar as well. -ryan 1. http://hg.microformats.org/tests 2. http://www.w3.org/TR/2005/NOTE-test-metadata-20050914/ 3. http://www.w3.org/Style/CSS/Test/testsuitedocumentation.html 4. http://www.w3.org/TR/2005/NOTE-test-metadata-20050914/ 5. http://www.w3.org/Style/CSS/Test/guidelines.html#kinds 6. http://www.w3.org/Style/CSS/Test/ testsuitedocumentation.html#usingtestsuites 7. http://www.w3.org/TR/2005/NOTE-test-metadata-20050914/#purpose-def 8. http://www.w3.org/TR/2005/NOTE-test-metadata-20050914/#status-def From ryan at technorati.com Wed May 30 10:47:23 2007 From: ryan at technorati.com (Ryan King) Date: Wed May 30 10:47:26 2007 Subject: [uf-dev] hAtom atomic tests Message-ID: As hinted at by a previous email[1], I'm starting to organize our test suite into something with a bit more structure. hAtom is currently on my plate for implementation, so I'm focusing on that. I just pushed a changeset[2] to the mercurial respository that adds some atomic tests for hAtom [3]. Please give feedback if you have any suggestions for improvements. -ryan 1. http://microformats.org/discuss/mail/microformats-dev/2007-May/ 000325.html 2. http://hg.microformats.org/tests? cmd=changeset;node=ef2a531a19ac;style=gitweb 3. Atomic tests for hAtom were actually pretty hard to write. Atomic tests should be as simple and isolated as possible, but it turns out that Atom has some non-trivial requirements for creating valid documents. From bsittler at gmail.com Wed May 30 17:11:57 2007 From: bsittler at gmail.com (Ben Wiley Sittler) Date: Wed May 30 17:12:04 2007 Subject: [uf-dev] hAtom atomic tests In-Reply-To: References: Message-ID: nice! i have tried a few of the tests, and intend to try more. i notice the tests use the same interpretation of "concatenation" as hAtom2Atom.xsl, but that's an issue for discussion on the list and/or wiki, not a bug. On 5/30/07, Ryan King wrote: > As hinted at by a previous email[1], I'm starting to organize our > test suite into something with a bit more structure. > > hAtom is currently on my plate for implementation, so I'm focusing on > that. I just pushed a changeset[2] to the mercurial respository that > adds some atomic tests for hAtom [3]. > > Please give feedback if you have any suggestions for improvements. > > -ryan > > 1. http://microformats.org/discuss/mail/microformats-dev/2007-May/ > 000325.html > 2. http://hg.microformats.org/tests? > cmd=changeset;node=ef2a531a19ac;style=gitweb > 3. Atomic tests for hAtom were actually pretty hard to write. Atomic > tests should be as simple and isolated as possible, but it turns out > that Atom has some non-trivial requirements for creating valid > documents. > _______________________________________________ > microformats-dev mailing list > microformats-dev@microformats.org > http://microformats.org/mailman/listinfo/microformats-dev > From ryan at technorati.com Thu May 31 10:36:15 2007 From: ryan at technorati.com (Ryan King) Date: Thu May 31 10:36:20 2007 Subject: [uf-dev] hAtom atomic tests In-Reply-To: References: Message-ID: <4EA50F3A-4E40-4FED-9D29-4B410D262224@technorati.com> On May 30, 2007, at 5:11 PM, Ben Wiley Sittler wrote: > nice! i have tried a few of the tests, and intend to try more. > > i notice the tests use the same interpretation of "concatenation" as > hAtom2Atom.xsl, but that's an issue for discussion on the list and/or > wiki, not a bug. A number of the tests were written to support hAtom2Atom.xsl and may have some extensions or misinterpretations. Currently (personally) only endorse the atomic tests (those whose filenames start with 'a0x-'). -ryan > On 5/30/07, Ryan King wrote: >> As hinted at by a previous email[1], I'm starting to organize our >> test suite into something with a bit more structure. >> >> hAtom is currently on my plate for implementation, so I'm focusing on >> that. I just pushed a changeset[2] to the mercurial respository that >> adds some atomic tests for hAtom [3]. >> >> Please give feedback if you have any suggestions for improvements. >> >> -ryan >> >> 1. http://microformats.org/discuss/mail/microformats-dev/2007-May/ >> 000325.html >> 2. http://hg.microformats.org/tests? >> cmd=changeset;node=ef2a531a19ac;style=gitweb >> 3. Atomic tests for hAtom were actually pretty hard to write. Atomic >> tests should be as simple and isolated as possible, but it turns out >> that Atom has some non-trivial requirements for creating valid >> documents. >> _______________________________________________ >> microformats-dev mailing list >> microformats-dev@microformats.org >> http://microformats.org/mailman/listinfo/microformats-dev >> > _______________________________________________ > microformats-dev mailing list > microformats-dev@microformats.org > http://microformats.org/mailman/listinfo/microformats-dev