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