[uf-discuss] parsing hCalendar categories clarification

[Tantek Ç elik]

Hi Mark,

On 1/4/06 8:57 PM, "Mark Mansour" <mark at lifelint.com> wrote:

> Hi uF list,
> 
> I'm writing a hCalendar parser

Great!


> and I'm using the content on
> http://microformats.org/wiki/hcalendar-examples as my baseline tests.

Excellent.  Using examples as tests is a very good thing.


> My question may be caused by a lack of understanding of the 'microformats
> way' but I would like to know if there is a single way of representing the
> categories property of a hCalendar?

Yes, there is, the same way as categories are represented in hCard (which is
better documented than hCalendar currently).


> The reason for my confusion is that the categories hCal properties is
> represented in 3 different ways...
> 
> a) In "4.6.1 Event Component" (
> http://microformats.org/wiki/hcalendar-examples#4.6.1_Event_Component) you
> have:
> <ul>
>   <li class="category">Business</li>
>   <li class="category">Human Resources</li>
> </ul>

This is minimally correct.

It could be more semantic with the use of rel-tag for the tags.


> b) in "Example 5: journal entry category" (
> http://microformats.org/wiki/hcalendar-examples#Example_5:_journal_entry)
> there is
> <ul class="category">
>   <li>Project Report</li>
>   <li>xyz</li>
>   <li>Weekly Meeting</li>
> </ul>

This is incorrect.


> c) and in "5. iCalendar Object Examples, example 1" (
> http://microformats.org/wiki/hcalendar-examples#5._iCalendar_Object_Examples)
> you have:
> <ul class="categories">
>    <li>Conference</li>
> </ul>

This is the old way of doing it but also incorrect.


> a) is fine for me though it takes more work to convert 'category' to
> 'categories' for an ical

It's actually easier, as you don't have to do any special parsing of commas
or anything else to determine the "set" of categories.  You just have to
iterate through all elements with a class name of "category" and then append
them together with commas.


> b) I think this is wrong since the ical property used is "CATEGORY" but the
> RFC says it should be "CATEGORIES"

Certainly there is a disconnect between the singular property name and the
multiple values.


> c) this would be fine too, but both a) and c) are valid there are now lots
> of ways (ok, 2) to parse the XHTML.

Your analysis is correct, and that is one of the reasons why only (a) is
correct.


> my preferred method of expressing categories would be as follows, but I
> don't know if this format is still in flux...
> <ul>
>   <li class="categories">Business</li>
>   <li class="categories">Human Resources</li>
> </ul>

The problem with this is another disconnect, a plural form is used to
indicate a singular value.

> So which is correct?  Are they all correct and they all need to be
> understood?  Some guidance would be appreciated.

Only (a).

You have found bugs in the hcalendar-examples page.  Well done!

I haven't had a chance to fully verify it, however I will do so now and
address at least the bugs you found hopefully do a general once over.


> Also, what is the ettiqette for updating the uF wiki?  Just get in there and
> go for it or pass it through a moderator?  One of the examples needs to be
> updated because the XHTML is incorrect "<span class="rsvp">TRUE></span>" -
> notice the text is "TRUE>"

Definitely jump in a fix such obvious typo/spelling errors.

If you have any doubts, feel free to ask on the IRC channel, or here in
email is fine also.


> I'm looking forward to your replies (hopefully)

Note that the singular vs. plural issue was one of the primary issues that
was discovered when writing the hcard-parsing document,

 http://microformats.org/wiki/hcard-parsing#ISSUE_1

and resolved with additional details in the Semantic XHTML Design
Principles:

http://microformats.org/wiki/Template:semantic-xhtml-design-principles

"Plural components are made singular, and thus multiple nested elements are
used to represent multiple text values that are comma-delimited."

This was the last major change to hCard, and it has been VERY stable since.

We are still in the process of specifying hCalendar with as much detail as
hCard.  

Thus if you find anything else "weird" with hCalendar, take a look at the
equivalent in hCard and see if there is a clearer answer tere.

Thanks very much for bringing these apparent inconsistencies/problems to
everyone's attention.

Tantek