On 1/17/06 3:10 AM, "Mark Mansour" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> >> >> _______________________________________________ >> microformats-discuss mailing list >> microformats-discuss@microformats.org >> http://microformats.org/mailman/listinfo/microformats-discuss >> > > > -- > picking the lint of your life > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
