[uf-discuss] hCalendar anchors...

[Tantek Ç elik]

On 1/17/06 3:10 AM, "Mark Mansour" <mark at lifelint.com> wrote:

> Ben and Brian,
> 
> Thanks for the clarification.  I've taken a look at the hCard parsing
> document and its made things clearer and simpler.  But I would add
> that the parsing instructions aren't totally unambiguous.

Mark,

Thanks *very much* for reviewing the hcard-parsing document.  I very much
appreciate your attention to detail and feedback.

Any place you find something unambiguous in the slightest, let me know.

> For instance, I've had troubles with example 6 because of the parsing
> rule which says:
>  "Once an element for a property is found, the contents of the
> element are used for the value"
> but then it says
>  For properties that may take type URI ... <a href>: use the value
> of the 'href'

Correct.


> and if you do that then you have a summary value that is a URL.

You can't, because 'summary' is NEVER of type URI/URL per RFC 2445.


> I mean, why can't a summary be a URL?

Because the spec says so:

RFC 2445:

4.8.1.12 Summary

   Property Name: SUMMARY

   Purpose: This property defines a short summary or subject for the
   calendar component.

   Value Type: TEXT

Done.


> I guess you are implicitly saying
> that the iCalendar "summary" property cannot have a value of URL and
> that is the bit that isn't obvious.

Not "implicit" at all.

   Value Type: TEXT

means text.  Means you can't assume anything else about the value at all.
It could *look* like a URL to a human if you wanted to put a text URL in
there, but from a parsing perspective, it's a text string, plain and simple.


> What's the solution?  I guess a list of properties that are URLs
> should be listed for each microformat.

For each new microformat sure, but for hCard and hCalendar, as an
implementer, you MUST (RFC2119) read the respective RFCs: 2426 and 2445.

> It is a limited set of data,
> so it should take too long to enumerate those values, but it is a bit
> of a PITA...

For microformats which are 1:1 representations of existing standards, we try
to avoid duplicating such information in the microformat specs.
Implementers are expected to read the RFCs.

Thanks,

Tantek


> On 1/17/06, Benjamin Carlyle <benjamincarlyle at optusnet.com.au> wrote:
>> On Sun, 2006-01-15 at 10:03 -0600, brian suda wrote:
>>> In your examples, i think you are confusing two things:
>>> 1) The general rule you proposed is not true, it depends on two things,
>>> first the TYPE of tag, behavior varies when it is an ABBR, A, IMG,
>>> OBJECT, etc. The second issues is that depending on the class value
>>> different areas are looked too for the TEXT.
>>> 
>>> so when we have class="url" AND it is an 'A' element it looks to the
>>> HREF, if it were an 'IMG' element with a class="url" it would look to
>>> the 'SRC' attribute. (i'm not sure if all of this is documented on the
>>> wiki or not?) The hCard parsing page[1] has many of the rules for hCard
>>> which are the same as hCalendar.
>> 
>> 
http://microformats.org/wiki/hcard-parsing#parsing_hCard_properties_and_valu
e>> s
>> 
>> I believe this is supposed to be a general parsing ruleset across
>> microformats, however presumably individual microformats could define
>> special rules for special circumstances.
>> 
>> --
>> Benjamin Carlyle <benjamincarlyle at optusnet.com.au>
>> 
>> _______________________________________________
>> microformats-discuss mailing list
>> microformats-discuss at microformats.org
>> http://microformats.org/mailman/listinfo/microformats-discuss
>> 
> 
> 
> --
> picking the lint of your life
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss