Re: [uf-discuss] Possible alternative methods for "include"
I'm standing back from this discussion until I've updated the include- pattern documentation itself, since I feel my participation would be premature otherwise. The update following on our research at Yahoo is drafted and will happen once I've cleared a handful of other items from my actions list. In the meantime… On 26 Jan 2008, at 16:35, Jim O'Donnell wrote: Is the include pattern really necessary, for hResume at least? Given that each hCard describing a previous position is enclosed inside a hResume, and given that the resume itself has a card with contact details, including an fn for a person, can't a parser allow the enclosed hCards to inherit the fn from that top-level hCard? This strikes me as absolutely the correct way to consider the problem. Off the top of my head the only spec which has an absolute demand for including no content-text is hResume — hReview is generally reusing an entire item, such that a small piece of relevant inner text is not duplication to the same degree. If this is a valid problem, then revisiting hResume to see whether it still _needs_ to use the include pattern at all would be a better first step than jumping straight in with a mark-up solution. I defer to hResume experts for feedback on that. But confirmation of the continued include-pattern requirement would be appreciated. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Possible alternative methods for "include"
Andy Mabbett wrote: In message <[EMAIL PROTECTED]>, Guillaume Lebleu <[EMAIL PROTECTED]> writes Andy Mabbett wrote: A brainstorm of possible alternative methods of using include in microformats, avoiding the use of the problematic "OBJECT" or empty-link variants: What about: my address Birmingham ? That seems to presume, wrongly, a 1:1 relationship between the included data and the microformat. Consider: my address my second address Birmingham Sorry for the late response. In this case, I would group the two "adr" in a container and have the href point to that container. For instance: Our company has offices at two addresses in rev="propertyOf">San Francisco: id="adrlist1"> class="street-address">665 3rd Street, and class="adr">123 Folsom. adr1 and adr2 inherit the property attached to their parent ul. It also requires publishers to make a within-page link, where none existed previously. I am not sure what you mean. I don't see why this is such a problem when we require them to markup content anyhow. Furthermore, "rev" is deprecated for use in microformats. Ok, sorry I had missed point 2.10 in the rel page. I won't push the above idea further in this case, but since there is not much content in there that justifies the decision, I'd appreciate any pointer anyone has about how rev came to be deprecated in microformats. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Possible alternative methods for "include"
In message <[EMAIL PROTECTED]>, Jim O'Donnell <[EMAIL PROTECTED]> writes Is the include pattern really necessary, for hResume at least? The include pattern is used in many microformats (and potentially many more to come) It is in the interests of all concerned (i.e. publishers, parsers and the authors of future specs) that it works the same way in all of them. -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Possible alternative methods for "include"
Is the include pattern really necessary, for hResume at least? Given that each hCard describing a previous position is enclosed inside a hResume, and given that the resume itself has a card with contact details, including an fn for a person, can't a parser allow the enclosed hCards to inherit the fn from that top-level hCard? Alternatively, following on from the discussions here about cards for places and organisations, couldn't an author mark up the organisation in a previous position with class="fn org", thus obviating the need for a separate fn in the first place? Jim Jim O'Donnell [EMAIL PROTECTED] http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Possible alternative methods for "include"
In message <[EMAIL PROTECTED]>, Guillaume Lebleu <[EMAIL PROTECTED]> writes >Andy Mabbett wrote: >> A brainstorm of possible alternative methods of using include in >> microformats, avoiding the use of the problematic "OBJECT" or empty-link >> variants: >What about: > >my address > >Birmingham > >? That seems to presume, wrongly, a 1:1 relationship between the included data and the microformat. Consider: my address my second address Birmingham It also requires publishers to make a within-page link, where none existed previously. Furthermore, "rev" is deprecated for use in microformats. -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Possible alternative methods for "include"
Andy Mabbett wrote: A brainstorm of possible alternative methods of using include in microformats, avoiding the use of the problematic "OBJECT" or empty-link variants: Birmingham then: [...] What about: my address Birmingham ? The idea is that: ... ... The shortcut notation is convenient when properties are grouped together in the HTML tree (usually the case), while the subject/predicate/object works in any case. In other words, in the first case, you can view the parent/child relationship (span of class "adr" is the parent element of span of class="locality") as overloaded semantically: it means both "part of" (in HTML) and "property of" (in microformats). Don't mean to start a debate on properties vs relationships... Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Possible alternative methods for "include"
In message <[EMAIL PROTECTED]>, Andy Mabbett <[EMAIL PROTECTED]> writes >Birmingham > >then: [...] >or > >[...] or [...] or [...] or [...] -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Possible alternative methods for "include"
A brainstorm of possible alternative methods of using include in microformats, avoiding the use of the problematic "OBJECT" or empty-link variants: Birmingham then: [...] or [...] or [...] or [...] or Birmingham [...] [...] Note: "birminghamid" used for clarity; "birmingham" would be the semantically correct value. -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
