[uf-discuss] Nested Microformats and Operator

[Brian Suda]

On 8/28/07, Mike Kaply <microformats at kaply.com> wrote:
> hCalendars for experience are interesting, but unuseful as hCalendars.
> And hCards for my employment at a past employer aren't terribly interesting either.

--- well, that´s the tricky part. It might be un-interesting to you
personally right this minute but not for all times and all people.

> Should there be a way for people to have this information but not make
> it available as a vcard or vevent?

--- i think this falls into the "let the market sort it out".
Microformats only define the markup. How it gets rendered in a GUI,
what parts are extracted, how apps deal with nested data, is  outside
the scope of the FORMAT.

If Operator chooses to be "smart" and not add class="location vcard"
to the list of hCards because it is a VENUE address, then that is
completely up to the application. The FORMAT itself does not have
control of that. What will drive these answers is when people WANT
operator to detect it and it doesn´t then they move to a competitor's
plugin... if Operator wants more market share, then it "gets smarter"
and uses more heuristics, checking if a class="experience vevent"
exists and tries to deal with it appropriately. Just look now, with
vCards, Outlook and Apple and others import or don't import certain
fields... that is an application choice, not something controlled by
the spec.

On 8/28/07, Michael MD <mdagn at spraci.com> wrote:
> or a way to tell what kind of thing the vevent or vcard represents?
> (so that a parser can work out how it should be displayed based on criteria
> chosen by the user)

Microformats have ALWAYS been about pushing the hard work to parsers
NOT the publishers. So i would suggest we avoid trying to invent
anything which explicitly tells parsers "this is a vcard, but not in
this circumstance, unless it is this a specific parser and the day is
equal to the BBDAY in the vcard" That is WAY to much work for
publishers, let the few parsers do all the heavy lifting.

by using things like class="education vevent" parser can determine
further that it is a "typed" event of education. How and What the
parser does, should (IMHO) be left up to the parser. Maybe a "smart"
and a "verbose" mode.

On 8/28/07, Andrew Jaswa <ajaswa at gmail.com> wrote:
> Would it be possible in the case of the hResume to ignore the nested
> hCards and hCalendars and to make a "primary" hCard that could be then
> downloaded?

--- it certainly could. Nothing in the hCard/hCalendar spec says that
you MUST display all data you found, even if it is annoying, in error
and pisses off the user. Operator and other could attempt to "be
smart" and not (or display differently) the data inside an hResume.
The problem with "being smart" is that you will be wrong too, and you
need to decide if you want to field Q&A and bugs about why hCard ARE
or ARE NOT appearing, because depending how they choose to "be smart"
someone will think it is the wrong way.

> I guess this then leads into the question (but may be off topic): is
> there a way for the entire hResume to be downloaded and not just the
> parts?

this is not really even public, but i spent some time working on XSLT
to convert hResume to XML:
http://suda.co.uk/projects/microformats/hresume/

On 8/28/07, Michael MD <mdagn at spraci.com> wrote:
> Is a nested hCard or adr or geo in a vevent for the venue/location of the
> event or is it for the organiser of the event
> or for someone attending the event?

--- there currently are parsing rules for singleton instance of
properties. Both hCalendar and hCard can take a GEO property. The
first GEO property found after the root property (vcard or vevent)
will be used as the GEO for that instance. So something like the
following code would NOT get confused:

- vevent
-- hcard & location
--- geo
-- vcard attendee
--- geo

this would correctly associate the GEO with the right groupings.

that said, there has not been much work around attendees and other
people properties associated with vevents. Partly due to lack of
interest, implementations and focus on higher priority things.

> Marking up the venue location is probably the most common use of nested
> hCard in hCalendar but the other cases are certainly possible.
>
> How would a parser know which it is?

--- i don´t see this as an issue. the iCalendar spec does NOT have
structured data for the location, so the class="vcard location", no
matter what follows, structured or unstructured would be correctly
found by the iCalendar parser due to the class="location" multiple
instances of a class="vcard" would not effect this.

A "smart" parser could look for both the "location vcard" combination
and ignore other class="vcards" that might be used to describe people,
ticket sales, etc. But in some instances you actually DO WANT those
other vcards to be pulled out by operated and displayed somehow so you
can go get tickets.

On 8/28/07, Paul Wilkins <paul_wilkins at xtra.co.nz> wrote:
> A parser could provide the ability to extract just the top-level elements.

--- correct, nothing prohibits this. The tricky thing is that ADR and
GEO are independant, so inside an hCard they should/shouldn´t be
ignored? for display reasons i agree, for export reasons you should
keep as much data together. But generally, yes in Operator you COULD
not display vevent and vcard that are nesting in an hresume - that is
completely up to the parser.

> The other elements could be accessed from a tree view, if you're looking
> at an overall structural view.

--- i like these suggestions. They are examples of ways to solve the
problem, #1 independent of the spec or the format. #2 put the work on
the parser, not the publisher, #3 can easily evolve with the times,
the GUI, etc rather than potentially be baked incorrectly into the
specs and ruin it for the future.

This is more of an discussion point for parsers and plugins than for
the specs. My vote is to let the parsers do what they THINK is best
and we vote collectively with our installs and/or bug reports.

Also, if there are specific parsing questions, then please take them
to the mf-dev list.

-brian

-- 
brian suda
http://suda.co.uk