Re: [uf-discuss] Nested Microformats and Operator

[Andy Mabbett]

In message
<[EMAIL PROTECTED]>, Brian
Suda <[EMAIL PROTECTED]> writes

>--- 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

But what if there is no GEO for the location:

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

or if the order is reversed on the page:

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

How can we cater for such circumstances?

-- 
Andy Mabbett
*  Say "NO!" to compulsory UK ID Cards:  
*  Free Our Data:  
*  Are you using Microformats, yet:  ?
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Nested Microformats and Operator

[Jason Calabrese]

I'm going to reply to a couple of posts:

> Only if that's a user-configurable option, please. Some of use Operator
> for debugging.

I think the debug mode should always show all the available microformat 
elements.


> A parser could provide the ability to extract just the top-level elements.
>
> The other elements could be accessed from a tree view, if you're looking
> at an overall structural view.
>
> If you're looking at hcards, they could be notated to indicate which
> ones are embedded and which ones are not.

I like the idea of using a tree view.  It seems like the presentation of 
nested elements should determinded by the user scripts for the composite 
microformats.

For example the hResume script could some tell Operator not to show the nested 
hCard's and hCalendar events and then display the nested data in a tree like 
structure if it make sense to display the nested elements.  This way the 
contact hCard of an hResume would be displayed as a nested menu item if you 
are using the toolbar, but the other hCards and vevents wouldn't be 
displayed.

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Nested Microformats and Operator

[Brian Suda]

On 8/28/07, Mike Kaply <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> A parser could provide the ability to extract just 

Re: [uf-discuss] Nested Microformats and Operator

[Andy Mabbett]

In message 
<[EMAIL PROTECTED]>, Andrew 
Jaswa <[EMAIL PROTECTED]> writes


Would it be possible in the case of the hResume to ignore the nested 
hCards and hCalendars


Only if that's a user-configurable option, please. Some of use Operator 
for debugging.


--
Andy Mabbett
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Nested Microformats and Operator

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Michael MD
<[EMAIL PROTECTED]> writes

>> Should there be a way for people to have this information but not make
>> it available
>> as a vcard or vevent?
>
>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)

Yes; greater granularity is good.

>I think there may be another similar problem with using hCalendar data
>with nested hCards or adr's.
>
>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?

Consider hCalendars, with class="location vcard" for the event's venue.
It's the job of parsers to distinguish between such hCards, and, say,

class="attendee vcard"

and
class="organizer vcard"

(I note that "attendee", "contact" and "organizer" are listed in the
hCalendar spec, but not the cheat-sheet. Do any current parsers
recognise them? Should we also have a "speaker" or similar class?

-- 
Andy Mabbett
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Nested Microformats and Operator

[Paul Wilkins]

Michael MD wrote:
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?


A parser could provide the ability to extract just the top-level elements.

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


If you're looking at hcards, they could be notated to indicate which 
ones are embedded and which ones are not.


--
Paul Wilkins
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Nested Microformats and Operator

[Alex Faaborg]

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


The user-action class or new protocols proposed in the Firefox 3  
thread could address this problem (10 hCards in an hResume).  Since  
these pieces of microformatted content probably would not contain a  
user-action (or link with a particular protocol), the browser would  
not expose them to the user.


-Alex



On Aug 27, 2007, at 7:14 PM, Mike Kaply wrote:


I wanted Jason to bring this up on the list because it is an
interesting discussion.

We display lots of stop in Operator (especially in hResume) that can't
actually be used.

hCalendars for experience are interesting, but unuseful as hCalendars.
And hCards for
my employment at a past employer aren't terribly interesting either.

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

Mike

On 8/27/07, Jason Calabrese <[EMAIL PROTECTED]> wrote:
I've recently started to look into using some microformats on one  
of my
projects and have been playing with Operator to get an idea of how  
they are

being used elsewhere.

Operator is a great way to see what microformats are contained on  
a page, but
I think it might confuse the average user when a page contains a  
lot of
nested data using core microformats such as hCard, adr, hCalendar,  
etc.


For example on a LinkedIn public profile:
http://www.linkedin.com/in/steveganz

You see 1 hResume, 1 adr, 10 hCard's, and 7 hCalendar's.

In this case all the hCalendar events are from the experience part  
of the
resume.  I don't see any use for adding these to Google Calendar  
or exporting
them.  Also 9 of the hCard's wouldn't make sense to export or add  
to Yahoo

Contacts since they contain only very basic information.

An other example is a Google Maps search.  In this case each  
result produces a
hCard and contains an adr.  Ideally these would be combined and  
shown as
Contacts with addresses. Then each contact could be exported or  
viewed in

Google or Yahoo maps.

Have these types of issues been discussed before?  Is there a way  
that a user

script can hide nested data?

I understand the value of reusing the core microformats and  
creating composite
microformats.  I think that in many cases users will want to  
interact with
the primary composite format while still preforming actions based  
on the

nested content.

___
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


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Nested Microformats and Operator

[Michael MD]

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


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)


I think there may be another similar problem with using hCalendar data with 
nested hCards or adr's.


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?

other possibilities exist too - such as where to get tickets for an event...

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?



___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Nested Microformats and Operator

[Andrew Jaswa]

On 8/27/07, Mike Kaply <[EMAIL PROTECTED]> wrote:

> And hCards for
> my employment at a past employer aren't terribly interesting either.

I brought this up before[1]. While its the semantic thing to do its
not overly useful.


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

I would say yes.


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?

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?

- Andrew

[1]http://microformats.org/discuss/mail/microformats-discuss/2007-May/009685.html
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Nested Microformats and Operator

[Mike Kaply]

I wanted Jason to bring this up on the list because it is an
interesting discussion.

We display lots of stop in Operator (especially in hResume) that can't
actually be used.

hCalendars for experience are interesting, but unuseful as hCalendars.
And hCards for
my employment at a past employer aren't terribly interesting either.

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

Mike

On 8/27/07, Jason Calabrese <[EMAIL PROTECTED]> wrote:
> I've recently started to look into using some microformats on one of my
> projects and have been playing with Operator to get an idea of how they are
> being used elsewhere.
>
> Operator is a great way to see what microformats are contained on a page, but
> I think it might confuse the average user when a page contains a lot of
> nested data using core microformats such as hCard, adr, hCalendar, etc.
>
> For example on a LinkedIn public profile:
> http://www.linkedin.com/in/steveganz
>
> You see 1 hResume, 1 adr, 10 hCard's, and 7 hCalendar's.
>
> In this case all the hCalendar events are from the experience part of the
> resume.  I don't see any use for adding these to Google Calendar or exporting
> them.  Also 9 of the hCard's wouldn't make sense to export or add to Yahoo
> Contacts since they contain only very basic information.
>
> An other example is a Google Maps search.  In this case each result produces a
> hCard and contains an adr.  Ideally these would be combined and shown as
> Contacts with addresses. Then each contact could be exported or viewed in
> Google or Yahoo maps.
>
> Have these types of issues been discussed before?  Is there a way that a user
> script can hide nested data?
>
> I understand the value of reusing the core microformats and creating composite
> microformats.  I think that in many cases users will want to interact with
> the primary composite format while still preforming actions based on the
> nested content.
>
> ___
> 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