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