[uf-discuss] uf on mobile devices

[Andy Mabbett]

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

>Quite a lot of phones in recent years appear to have some (limited) support
>for iCal/vCard ... so online conversion tools or server-based tools may be
>the only practical way to go until phones with better browsers which include
>support for stuff like javascript reach consumer pricing levels and become
>more popular.

A version of Opera, "Opera Mini":



is available for some mobile devices - it is both free and good.

Perhaps the way forward is to lobby for such third-party add-ons to
offer better features, such as uF support, and hope the device makers
will then play catch-up with their own software.

>I thought the iPhone would be better than that.. but I haven't seen one yet.

>From the reviews I've read, I'm not surprised.

>I was always somewhat dismayed at the lack of support for transferring
>contacts/events/etc in any standard formats on many mobile devices .. I
>can't see the point of having something like a calendar on my phone if I am
>expected to re-enter everything by hand .. I (and I assume most people)
>couldn't be bothered doing that, so such a calendar ends up being nothing
>more than a waste of space!

I can't even copy plain text from web pages using the native browser on
my Nokia N95; nor for that matter, with Opera Mini - though I have more
confidence in the ability being added to the latter.

I do, though, synch my calendar with Outlook's calendar, which I use on
my desktop PC (and could also synch it with my Lotus Notes' calendar, at
work, except all my colleagues have access to that..!)

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

[uf-discuss] PD wording: inconsistency between wiki and blog

[Andy Mabbett]

The wording:

One way to address some of these concerns is for individual
contributors to decide for themselves if they'd like to put
their own individual contributions to the wiki, mailing lists,
blog, and IRC channel into the public domain.

[...]

If enough contributors eventually support this...

on:



would seem to be at odds with:

Editors will [...] remove past contributions from users who have
indicated that preference.

Starting February 1st, primary editors and authors of pages
should start cleaning microformats.org wiki pages created before
today of non-public-domain content [...]

When all pages are new or cleaned, the admins will move the text
of the CC-PD license to the global footer on the wiki, thus
indicating that the contents of the entire wiki is in the public
domain.

on:





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

Re: [uf-discuss] Multi-word tagging

[j...@eatyourgreens.org.uk]

There's often information in the full URL that allows you to place a tag in
context, so a clever enough bit of software should be able to figure out
that
http://flickr.com/photos/tags/stars/clusters/night-sky-longexposure/
is related to
http://en.wikipedia.org/wiki/Stars
but not to
http://en.wikipedia.org/wiki/Stars_%28UK_band%29
Slightly outside the boundaries of microformats tags, since they only use
the last portion of a URL.

I wrote something this morning that uses phrases, not single words, as
tags. Seems to work reasonably well with Operator. The URL is
http://www.nmm.ac.uk/rog/2008/01/will_an_asteroid_hit_mars_in_j.html
if you want to use it as an example or a test case.

Jim

Original Message:
-
From: Andy Mabbett [EMAIL PROTECTED]
Date: Wed, 2 Jan 2008 22:45:12 +
To: microformats-discuss@microformats.org
Subject: Re: [uf-discuss] Multi-word tagging


In message <[EMAIL PROTECTED]>, 
Jim O'Donnell <[EMAIL PROTECTED]> writes

>+ can indicate a space, but doesn't always. Which means you can't 
>necessarily relate a tag on Wikipedia, say, to a tag on flickr or 
>delicious.

Which is a pity. I suppose that horse has bolted, though. :-(

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



mail2web LIVE – Free email based on Microsoft® Exchange technology -
http://link.mail2web.com/LIVE



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

Re: [uf-discuss] uf on mobile devices

[Ciaran McNulty]

On Jan 3, 2008 12:33 PM, Andy Mabbett <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>, Michael MD
> <[EMAIL PROTECTED]> writes
> I can't even copy plain text from web pages using the native browser on
> my Nokia N95; nor for that matter, with Opera Mini - though I have more
> confidence in the ability being added to the latter.

Lack of cut+paste is indeed an annoyance with the N95.  The good news
is that it can handle most vCards or iCals correctly, if delieverd
over HTTP.

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

[uf-discuss] Tentative proposal: Sub-microformats to streamline common microformat patterns for simple data

[Andy Mabbett]

One of the microformat principles is (while not expressed in so many
words) that we should make life easier for publishers, and load work
onto parsers, instead.

There are a great many pages where a vCard is, or could be applied to a
single data-value (such as a name) in prose, or a table, without further
attributes being present; for example:

...as John Smith said...

Currently, that would require:

as John Smith
said

which is a considerable amount of mark-up, compared to the actual data,
and significantly bloats a page on which many such name appear.

Other examples might be:

...lived in Birmingham since 2005...

...developed by Acme Inc. using cheese...


It has previously been proposed that:

as John Smith said

be allowed, but that has been rejected; not least because it might break
existing microformats.


We could simply declare, in the manner of implied-n-optimisation, that
an hCard with no children:

as John Smith said

defaults to the equivalent of the full mark-up as used above. Still,
this again might break existing hCards, and could only apply in one case
(for an implied "fn", in this example), so must be rejected.


What we could do, though is create a LIMITED NUMBER of sub-microformats
(effectively, new microformats based on exiting microformats; I'd call
them "nanoformats", if that name was not already taken), using the name
and an attribute from one of those exiting microformats as the new
sub-microformat name.


We would have to be certain that these were limited to cases where vast
numbers of the relevant data items are published, and where the parsing
rules are unambiguous.

Such parsing rules might be:

   *John Smith

(treat content as fn within vCard; apply n-optimisation if
appropriate)

   *John Smith

(treat content as fn within vCard; apply n-optimisation if
appropriate, use URL)

   *mailto:[EMAIL PROTECTED]">
John Smith

(treat content as fn within vCard; apply n-optimisation if
appropriate, use e-mail address)


Further examples might be for organisations:

   *Acme Inc.

(vcard; with fn, and org, both set to "Acme Inc."; also used
with href as above)

and for places:

   *Birmingham

(vcard; with fn, and adr's locality, both set to "Birmingham")

   *Texas

(vcard; with fn, and adr's region, both set to "Texas")

[In each of the above pair, "vcard-" could be replaced with "adr-" and
parsed accordingly.]


Note again that I am NOT suggesting that all microformat attributes be
combinable in this manner; only a select few, which are deemed necessary
and agreed by consensus (perhaps only those shown above, plus a few
other adr-children; though the pattern could also apply to other,
upcoming microformats).

Benefits of using a single, unambiguously-named, class on a singe
element for simple, single-value data types will include ease of use for
publishers; and more widespread usage of semantic mark-up.

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

Re: [uf-discuss] Tentative proposal: Sub-microformats to streamline common microformat patterns for simple data

[Guillaume Lebleu]

Andy Mabbett wrote:

We could simply declare, in the manner of implied-n-optimisation, that
an hCard with no children:

as John Smith said


  
Why use the semantics of an electronic business cards standard to tag an 
entity's name? isn't this an example of hammering unfit-for-hcard 
content into hcard?


To me, if there is value in tagging and extracting entities from 
narrative Web content, it is a different problem than extracting contact 
information from a structured Web contact card, and as a result probably 
deserves its own class attributes, and maybe a microformat if that usage 
is widespread enough.


For now, in the example above the only thing that would make sense to me 
is an  link pointing to an anchor/id in the same/different page 
that would contain John Smith's contact information.


Guillaume

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

[uf-discuss] Tentative proposal: Sub-microformats to streamline common microformat patterns for simple data

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Guillaume Lebleu 
<[EMAIL PROTECTED]> writes



Andy Mabbett wrote:

We could simply declare, in the manner of implied-n-optimisation, that
an hCard with no children:

as John Smith said




Why use the semantics of an electronic business cards standard to tag 
an entity's name?


Because they're the most appropriate semantics; and because people are 
already using the long-hand version of hCard to do so.


vCard is an electronic business cards standard; hCard is not merely an 
electronic business cards standard, but already has wider uses.


I'm not suggesting a new use of those semantics; I'm merely suggesting a 
more efficient way of using them.



isn't this an example of hammering unfit-for-hcard content into hcard?


Clearly, I don't think so.

To me, if there is value in tagging and extracting entities from 
narrative Web content, it is a different problem than extracting 
contact information from a structured Web contact card, and as a result 
probably deserves its own class attributes, and maybe a microformat if 
that usage is widespread enough.


Are you suggesting that we use different class-names to mark up the same 
data? That's directly in contravention of the microformat "principles"; 
and would put more weight back onto the shoulders of publishers.


For now, in the example above the only thing that would make sense to 
me is an  link pointing to an anchor/id in the same/different 
page that would contain John Smith's contact information.


Who says that that information is one the page in question?

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

[uf-discuss] CSS for microformats

[Andy Mabbett]

I've posted a couple of CSS fragments which I use when publishing
microformats, and which others might also find useful:



Please feel free to reuse or improve them, and to post other examples.

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

Re: [uf-discuss] Tentative proposal: Sub-microformats to streamline common microformat patterns for simple data

[Guillaume Lebleu]

Andy Mabbett wrote:
Because they're the most appropriate semantics; 

I don't agree with that, but I'm not going to argue about it.
and because people are already using the long-hand version of hCard to 
do so.


vCard is an electronic business cards standard; hCard is not merely an 
electronic business cards standard, but already has wider uses.
Ok, I didn't know that. I'm really just raising a warning. I can think 
of at least one discussion here 
(http://microformats.org/discuss/mail/microformats-discuss/2007-November/010974.html) 
that was arguing how one of the wider uses of hCard, particular for 
microformatting narrative content might not be actually a publisher's 
best practice.


In addition, my experience in other communities is that favoring reuse 
over semantic precision can result in very difficult machine processing 
(due to disambiguation requirements), which may defeat the point of 
microformats: reusing the same tag/classname seems good at first, but 
then people realize that a particular tag/classname's meaning depends on 
the context, i.e. what other tags/classnames are present, and the 
processing complexity increases.


While microformats are for humans, I see microformats as a way to reduce 
the costs of "machine reading". If the meaning of a tag/classname is 
highly context-sensitive, then you may end up building the same "$1M 
code" that you would have to build if there was no microformat.


Are you suggesting that we use different class-names to mark up the 
same data? That's directly in contravention of the microformat 
"principles"; and would put more weight back onto the shoulders of 
publishers.

No. I don't think that's necessary.

I just think that the "John Smith" in your example "...as John Smith 
said in..." is different data than in "My contact information: John 
Smith Cell: (415) ...".


I would tag the "John Smith" in your example as an entity name, a 
formatted name, a person's name, a reference to an entity, but not as 
something that is also use for electronic business card. Otherwise, I 
have to look at the context to understand what I'm really supposed to do 
with this information. For instance, a software like tail will have to 
disambiguate between vcards that are merely a person name (and are not 
very valuable in my opinion to export to an address book) and vcards, 
which actually carry contact information.


In other words, my opinion is that a vcard implies a named entity, but a 
named entity does not imply a vcard.


In other words, I would be perfectly happy to simply microformat "...as 
John Smith said in..." as "... as John Smith 
said in...". I don't see the value of prefixing fn and n by vcard.


I'm probably missing something though, if so, let me know.



Who says that that information is one the page in question?

I assume you mean "on the page in question". I'm not saying it is. I'm 
saying that if it is not there, then the "John Smith" in "... as John 
Smith said in..." is not a contact card, but if there is such contact 
information for this person somewhere else on the page, or on a 
different page, then an  "... as href="http://johnsmith.com/home#JohnshCard";>John Smith said in..." 
is what would make sense to me.


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

Re: [uf-discuss] Tentative proposal: Sub-microformats to streamline common microformat patterns for simple data

[Paul Wilkins]

On Jan 4, 2008 6:00 AM, Andy Mabbett <[EMAIL PROTECTED]> wrote:
> There are a great many pages where a vCard is, or could be applied to a
> single data-value (such as a name) in prose, or a table, without further
> attributes being present; for example:
>
> ...as John Smith said...
>
> Currently, that would require:
>
> as John Smith
> said
>
> which is a considerable amount of mark-up, compared to the actual data,
> and significantly bloats a page on which many such name appear.
>
> Other examples might be:
>
> ...lived in Birmingham since 2005...
>
> ...developed by Acme Inc. using cheese...

What if the include pattern could be used without having to be inside an hcard?
as John Smith said

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

Re: [uf-discuss] Tentative proposal: Sub-microformats to streamline common microformat patterns for simple data

[Martin McEvoy]

Hello Paul, Andy...

On Fri, 2008-01-04 at 10:07 +1300, Paul Wilkins wrote:
> What if the include pattern could be used without having to be inside
> an hcard?
> as John Smith said 

You could wrap it in item:


John Smith


would the class-include work then?

Martin

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

Re: [uf-discuss] Tentative proposal: Sub-microformats to streamline common microformat patterns for simple data

[Martin McEvoy]

On Thu, 2008-01-03 at 21:44 +, Martin McEvoy wrote:
> You could wrap it in item:
> 
> 
> John Smith
> 
> 
> would the class-include work then? 

Operator and Tails don't have any issues with wrapping fn in an Item and
using the class include

http://weborganics.co.uk/files/test.html


x2v on the other hand chokes... er may need some "tweeking" to get it to
work.


Thanks

Martin


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

Re: [uf-discuss] Tentative proposal: Sub-microformats to streamline common microformat patterns for simple data

[Brian Suda]

On 03/01/2008, Martin McEvoy <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-01-03 at 21:44 +, Martin McEvoy wrote:
> > You could wrap it in item:
> >
> > 
> > John Smith
> > 
> >
> > would the class-include work then?
>
> Operator and Tails don't have any issues with wrapping fn in an Item and
> using the class include
>
> http://weborganics.co.uk/files/test.html
>
>
> x2v on the other hand chokes... er may need some "tweeking" to get it to
> work.

--- this is an issue with the description of the include pattern. X2V
will only look at encodings that are children of an ID, not at the
same level.

The following should work because it will find the node with the ID
and then find FN as a child:


John Smith


If we want to continue this conversation, it should be done on the dev-list

-brian

-- 
brian suda
http://suda.co.uk
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Tentative proposal: Sub-microformats to streamline common microformat patterns for simple data

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Martin 
McEvoy <[EMAIL PROTECTED]> writes



On Fri, 2008-01-04 at 10:07 +1300, Paul Wilkins wrote:

What if the include pattern could be used without having to be inside
an hcard?
as John Smith said


You could wrap it in item:


John Smith 

would the class-include work then?


That seems to be more bloated than the problem it sets out to solve...

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

[uf-discuss] hCard to represent simple entities (was: Tentative proposal...)

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Guillaume Lebleu
<[EMAIL PROTECTED]> writes

>Andy Mabbett wrote:
>> Because they're the most appropriate semantics;
>I don't agree with that, but I'm not going to argue about it.
>> and because people are already using the long-hand version of hCard
>>to  do so.
>>
>> vCard is an electronic business cards standard; hCard is not merely
>>an  electronic business cards standard, but already has wider uses.

>Ok, I didn't know that.

The hCard spec says that:

hCard is a simple, open, distributed format for representing
people, companies, organizations, and places, using a 1:1
representation of vCard (RFC2426) properties and values

note that's NOT:

hCard is a 1:1 representation of [a] vCard...

For clarity, the former can be distilled to:

hCard is for representing people, companies, organizations, and
places

>In addition, my experience in other communities is that favoring reuse
>over semantic precision can result in very difficult machine processing
>(due to disambiguation requirements)
[...]

I don't think my proposal, or the use outlined above, reduces semantic
precision. Note also that the *only* required property for an hCard is
"fn".

>I just think that the "John Smith" in your example "...as John Smith
>said in..." is different data than in "My contact information:
>John Smith Cell: (415) ...".
[...]

No. It *is* the same data. That's the crux of the matter.

>In other words, I would be perfectly happy to simply microformat "...as
>John Smith said in..." as "... as John Smith
>said in...". I don't see the value of prefixing fn and n by vcard.
>
>I'm probably missing something though, if so, let me know.

That the classes "fn" and/or "n" might already be used, with different
(or no) semantic meaning, to style the page in question?

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

Re: [uf-discuss] Tentative proposal: Sub-microformats to streamline common microformat patterns for simple data

[Martin McEvoy]

On Thu, 2008-01-03 at 22:55 +, Andy Mabbett wrote:
> In message <[EMAIL PROTECTED]>, Martin 
> McEvoy <[EMAIL PROTECTED]> writes
> 
> >On Fri, 2008-01-04 at 10:07 +1300, Paul Wilkins wrote:
> >> What if the include pattern could be used without having to be inside
> >> an hcard?
> >> as John Smith said
> >
> >You could wrap it in item:
> >
> >
> >John Smith 
> >
> >would the class-include work then?
> 
> That seems to be more bloated than the problem it sets out to solve...

That was my thought too, not really any point :), good to cover the
possibilities though?

Martin
> 

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

Re: [uf-discuss] hCard to represent simple entities (was: Tentative proposal...)

[Jim O'Donnell]

On 3 Jan 2008, at 23:04, Andy Mabbett wrote:


For clarity, the former can be distilled to:

hCard is for representing people, companies, organizations,  
and

places




Reference strings, in TEI markup at least, can also refer to the  
names of books, ships, plays, films and pretty much anything that can  
be given a name. hCard works for people and places, but is it general  
enough to cover those cases?


It would be handy to have a general method for preserving the  
semantics of the  tag (http://tei.oucs.ox.ac.uk/Query/tag.xq? 
name=rs) when converting TEI documents to HTML for delivery over the  
web. Particularly the contents of the type attribute, which  
identifies what class of thing we are referencing. Very useful when  
digitising historical manuscripts, diaries and letters, for example.  
In the past we've converted  to HTML links and left it to the  
reader to work out whether we're referring to a person, a place or a  
ship. For example, the links in this letter that we digitised years  
ago with TEI:

http://www.nmm.ac.uk/flinders/DisplayDocument.cfm?ID=110

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

[uf-discuss] hCard to represent simple entities (was: Tentative proposal...)

[Andy Mabbett]

In message <[EMAIL PROTECTED]>,
Jim O'Donnell <[EMAIL PROTECTED]> writes

>> For clarity, the former can be distilled to:
>>
>> hCard is for representing people, companies, organizations,
>>and
>> places

>Reference strings, in TEI markup at least, can also refer to the  names
>of books, ships, plays, films and pretty much anything that can  be
>given a name. hCard works for people and places, but is it general
>enough to cover those cases?

I think ships are an edge-case for hCard.

For books, plays and films, I would think that's a job for a "citation"
microformat, once we have one (and one is surely needed).

[One could argue that a physical copy of a book could have an hCard,
with an extended-address of "Shelf 54, Floor 3, Anytown Library"; but
that's really stretching the logic.]

As for "pretty much anything", I'll leave that for others to decide ;-)



I'm not familiar with TEI:

"a consortium which collectively develops and maintains a
standard for the representation of texts in digital form. Its
chief deliverable is a set of Guidelines which specify encoding
methods for machine-readable texts, chiefly in the humanities,
social sciences and linguistics.




- what does it have to teach us?

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

Re: [uf-discuss] hCard to represent simple entities (was: Tentative proposal...)

[Andy Mabbett]

In message <[EMAIL PROTECTED]>,
Jim O'Donnell <[EMAIL PROTECTED]> writes

>Reference strings, in TEI markup at least, can also refer to the  names
>of books, ships, plays, films and pretty much anything that can  be
>given a name. hCard works for people and places, but is it general
>enough to cover those cases?
>
>It would be handy to have a general method for preserving the
>semantics of the  tag (http://tei.oucs.ox.ac.uk/Query/tag.xq?
>name=rs)

P.S.

Having re-read the cited page, I see that the format is:

Joe Smith

and (I presume):

War and Peace

Since there are type delimiters, I would say that these parallel:

Joe Smith

and the hypothetical:

War and Peace


In other words:

rs-person -> hcard-fn

rs-book   -> hbook-fn

Though TEI allows any string as a value for "type", and microformats
require pre-defined "type" equivalents.

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

Re: [uf-discuss] hCard to represent simple entities

[Guillaume Lebleu]

Andy Mabbett wrote:


The hCard spec says that:

hCard is a simple, open, distributed format for representing
people, companies, organizations, and places, using a 1:1
representation of vCard (RFC2426) properties and values

note that's NOT:

hCard is a 1:1 representation of [a] vCard...

For clarity, the former can be distilled to:

hCard is for representing people, companies, organizations, and
places
  
I know, but I still think there is a sweet spot for hCard (portable 
friends list, distributed address book with personal electronic cards, 
anything use case that involves exchange of contact info of some sort), 
and still think that microformatting narrative content with hCard where 
there is no contact info and where people, organizations, and places' 
names are only used as references/identifiers is outside of that sweet 
spot. If there is no such sweet spot, then why excluding ships? they do 
have a name, location and contact info.


Another argument is that: if we microformat all people's names with 
hCard, then, if I want to style my actual electronic card from mere 
people's names/references/identifiers mentioned in my blog posts, I will 
have to wrap the hCard used for electronic cards into an element with a 
new classname to communicate precise meaning. So, IMO, I do lose 
semantic meaning by widening the use of hCard beyond its sweet spot.


But I won't argue with the spec. So, case closed AFAIC.

That the classes "fn" and/or "n" might already be used, with different
(or no) semantic meaning, to style the page in question?


Sorry if this is not really the point of the discussion, but what I'm 
reading here is that classname "fn" may have different meaning if used 
outside of an element of class "vcard".


Saying this is to me equivalent to saying the "vcard" classname syntax 
is syntactic sugar for the concept of a namespace (as is "vcard-fn"). My 
understanding was that the concept of namespace, not just its xml 
syntax, was an antipattern in microformats. Am I mistaken?


Re: styling, I believe I can use (at least in Firefox):

.hcard .fn { ... }

to specifically style the element of class fn found in an element of 
class hcard, and:


.fn { ... }

to specifically style elements of class fn, which do not appear within 
an element of class hcard.



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

Re: [uf-discuss] Tentative proposal: Sub-microformats to streamline common microformat patterns for simple data

[Ryan Cannon]

Andy Mabbett wrote:
> We could simply declare, in the manner of implied-n-optimisation, that
> an hCard with no children ... defaults to the equivalent of the full mark-up
> as used above. 

I wrote about this more than a year ago[1] and created some wiki pages with
examples:

  * http://microformats.org/wiki/hcard-implied
  * http://microformats.org/wiki/hcard-implied-examples
  * http://microformats.org/wiki/hcard-implied-brainstorming

It never got very much traction. The goal is to make it more quick and easy
to publish and capture the "personitude" (if you will) of a name and link.

Guillaume Lebleu  wrote:

> Why use the semantics of an electronic business cards standard to tag an
> entity's name?

Because that's what we've done in parts of hAtom[2], hresume[3] and probably
others since I've been more or less inattentive to this list.

The largest problem we have to deal with is one Brian Suda's criticism of
the idea[4]. Andy's solution begins where this discussion left off, but
there already has been some work done here.

[1]: 
http://microformats.org/discuss/mail/microformats-discuss/2006-November/0073
46.html
[2]: http://microformats.org/wiki/hatom#Schema
[3]: http://microformats.org/wiki/hresume#Schema
[4]: 
http://microformats.org/discuss/mail/microformats-discuss/2006-December/0075
59.html


-- 

Ryan Cannon

Application Developer
National Football League
http://ryancannon.com/


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