Re: [uf-discuss] Microformat for forms to post comments?

[Ben Ward]

On 2/23/06, Julien Couvreur <[EMAIL PROTECTED]> wrote:
> Hi,
>
Hi Julien!

> Most bloggers have the problem of following up on the comments they
> leave on other people's website. One of the challenges to solving this
> comment tracking problem is that comment forms come in many shapes.
> Would this be a good problem to solve with a microformat?
> Has any microformat of this kind been discussed before?
>
Aha, comment tracking: the bain of my life. Whilst I'm not totally
sure if hAtom has this in mind, I suspect that it could be used very
effectively for converting the comments pages of any blog into an Atom
feed and thus allow them to be tracked using a feed reader.

At the time of writing, Wordpress is the only mainstream blogging tool
I'm aware of that provides native feeds for every post (in RSS 2.0
format), but since hAtom allows you to describe a feed within the HTML
mark-up itself, it's a nicely CMS-agnostic solution for creating
individual post feeds.

> As a side question, do we know if some microformats really gained a
> lot of adoption? If so, which ones?
>
I believe XFN was taken under the Microformats umbrella, that's
popular. hCard is picking up too.


Regards,
Ben

(Apologies to list moderators as this message was previously
accidentally sent from an unvalidated address)
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Microformats to interlink desparate services

[Ben Ward]

Hi all,

I'd like to float an idea that I believe Microformats could play a
large part in.

A few weeks ago, I wrote a rather rough article on my blog [1] about a
way for people to host personal 'profile' information as part of their
own blog/webspace/etc. Any service or web application could request an
individual's profile information based on a URI.

Firstly, such a profile would contain contact information,
homepage(s), locations and other such fields that services like
Flickr, and older applications such as messageboards all request when
you register.

The first use-case is that rather than enter my details on a dozen
different sites (and have to maintain them all separately when I move
house), each service could just be given my URL and autofill as much
of the information as I provide. It would reduce hassle and time taken
to register for new services. What's more, this information can then
be automatically updated in the service when I update the profile on
my own site.

At the moment, this is hCard, perhaps with an additional pointer to
locate the hCard from a homepage (directing from
"http://ben-ward.co.uk"; to  "http://ben-ward.co.uk/about/";, for
example).

The second set of information I want to contain in a profile concerns
other services which I'm a member of.

Generally speaking, modern web services have a screenname, a personal
URL and a feed. But, there is no way of knowing that "BenWard" on
Flickr and "BenWard" on Upcoming.org are the same person. Furthermore,
there's no way of knowing that "BenWard" on Delicious is the same
person as "Shovel" on Last.FM. This profile file should therefore list
the common attributes of the standalone services, such that data from
all the separate services I use could be aggregated.

Not only could I aggregate disparate data, but the services I'm a
member at could use the profile to link to other content created by
the me.

To remove the need for disparate services to know each other by name,
each service listed in the profile would be tagged with interoperable
terms: Flickr tagged "Photographs", Delicious, Magnolia, Yahoo
MyWeb2.0 tagged "Bookmarks", Last.FM and Pandora both tagged "Music",
and so forth. As such, any service could include related content from
any other service based on a common tag, and the feed URI provided in
the profile.

This second part isn't hCard and if other people agree that this is a
good idea, it's the second part that I'd be interested to develop. (I
can't think of a clever name for it, maybe "hWebServices" or something
else that's, y'know, actually good).

The final part of my pre-draft was to specify a mandatory location for
this information. When I bodged together my blog post on the matter I
called it "profile.xml", believing that some invented XML format could
contain all the information. It was afterwards that I realised the
obvious use for hCard and that actually, presenting such a profile as
HTML has a lot of merit.

Perhaps, rather than require it to be a fixed file location (which may
not play well for lots of users), the profile could be pointed to by a
 on the first page served up by the person's
URI. That way it could be embedded into existing "about me" pages that
exist all over the web and could already contain an hCard.

The final thing, is that I don't know if this idea is new. If it's
come up before and everybody laughed, I apologise. I'm also acutely
aware that using the word "profile" in the context of HTML is a
potential cause for confusion, but I'm stuck for better terminology.
Feel free to swap it for something else.

Thank you,

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

Re: [uf-discuss] Chat microformat/podcast transcript

[Ben Ward]

On 4/14/06, Chris Messina <[EMAIL PROTECTED]> wrote:
> At least with DT and DD there's a clear correlation for the speaker
> with her/his words:
>

Chris, the one big problem I understand with DL for dialogue is
that it does not describe order. Or at least, that's the
interpretation/specification being put forward by the WHATWG in
WebApps 1.0[1] and goes so far as to explicitly note DL as being
inappropriate for mark-up.

Since chronology is vital to describing dialogue, Kevin Marks
OL+CITE+Q|BLOCKQUOTE example works much better for me. Appealingly it
also uses the same number of HTML elements as using the DL example.

[1] http://whatwg.org/specs/web-apps/current-work/#the-dl

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

Re: [uf-discuss] Chat microformat/podcast transcript

[Ben Ward]

On 4/19/06, Paul Bryson <[EMAIL PROTECTED]> wrote:
> One thing though, I use at least one chat program that has an option to
> condense all contiguous messages from a single author together so that it
> just displays the author once, but the timestamp of each message.
>

A couple of responses come to mind:

Firstly, that it could be acceptable to have multiple time+q pairs
within each list item, such that you might have:


  Ben
  12:38am First statement
  12:39am Additional Comment
  
  Paul
  12:40am Response
  


A generator application could then append ABBR+Q to the previous li
content as appropriate, thus the restriction would come out as 'one
CITE per LI with all other LI content attributable to that person'.
Which makes a certain amount of sense.

The alternative would be to say that you could potentially handle the
condensed rendering at render-time. What you're effectively
determining is the display: property of each LI > CITE. However, since
that would be dependent on the innerText of a predecessor's child,
which is well out of range of current CSS2 and proposed level 3
Selectors. Therefore such rendering would require scripting for this
kind of presentation on the web.
That's drifting off topic I think, I'm not sure how much of a
consideration that would be at this stage. With respect to
presentation though, I think flexibility (such as multiple abbr+cite)
is useful.


On a different tack (and this is not a suggestion that I especially
advocate, but I think it's valid to raise it for sake of clear
dismissal): It could be argued that each message is actually an event
in the conversation. Therefore, should there be reuse of hCalendar
here?

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

Re: validating microformats (was Re: [uf-discuss] Google Gdata new syndication protocol!)

[Ben Ward]

That's excellent Mark.

I have a small additional suggestion for 'validator' feedback, that
concerning common errors in naming conventions: Such as the use of a
'middle-name' classname when 'additional-names' was intended. Also
'locality', 'region', 'postal-code', 'country-name' can be misentered
as 'city', 'county', 'zip' or 'zip-code' and 'country' respectively.

I've seen at least one instance of those sorts of errors come up in
examples on this list just last week. I think generating warnings for
those and similar occurrences would be appreciated.

Regards,
Ben

On 4/21/06, Mark Pilgrim <[EMAIL PROTECTED]> wrote:
> On 4/21/06, Mark Pilgrim <[EMAIL PROTECTED]> wrote:
> > Perhaps the only way to convince you that a microformats validator would
> > be useful is to build the validator I'm imagining and show you.
>
> On the road to working code, here are some notes I threw together on
> the sorts of things I would expect a microformats validator to catch.
> I concentrated on hCard since it's complex and I'm familiar with it,
> but many of the rules would apply to any microformat.
>
>
>
> Errors (the W3C's XHTML validator won't catch any of these):
>
> - Properties that are supposed to have a URI value but do not conform
> to RFC 3986
>
> This is a photo if my
> dog
>
> - URI property with data: URI value that does not conform to RFC 2397
>
> - email property value with a mailto: URI that does not conform to RFC 2368
>
> - date property with non-date value (or illegal date, or date in wrong format)
>
> April 21th, 2006
> 1993-06-31
> 1993-10-15T25:01:00Z
> April 21th, 2006
>
> - geo/latitude and geo/longitude properties with improper values
>
> North
> America
>  class="latitude">370
>
> - Section 2.4.3 of RFC 2426 says phone numbers are supposed to conform
> to [CCITT E.163] and [CCITT X.121] (haven't looked into those yet)
>
> - tz property value that does not conform to section 2.4.4 of RFC 2426
>
> - agent property value that is not an hCard
>
> - required FN property missing (see section 1 of RFC 2426)
>
> -  without title attribute (see
> http://microformats.org/wiki/hcard#Human_vs._Machine_readable )
>
> -  without an alt attribute (only an error if it has an hCard
> class that is not a URI property, see
> http://microformats.org/wiki/hcard#Human_vs._Machine_readable )
>
> - illegal property present (NAME, PROFILE, SOURCE, PRODID, VERSION,
> see http://microformats.org/wiki/hcard#Property_Exceptions )
>
> -//ONLINE
> DIRECTORY//NONSGML Version 1//EN
>
> - more than one sort-string property present
>
> 
> 
>  Robert
>  Pau
>  Shou Chang
> 
> 
>
> - N property present and non-empty when FN and ORG properties are also
> present and have the same value as each other (see
> http://microformats.org/wiki/hcard#Organization_Contact_Info )
>
> - N property missing and FN property is not exactly two words
> separated by whitespace (see
> http://microformats.org/wiki/hcard#Implied_.22n.22_Optimization )
>
>
>
> Warnings (may indicate publishing errors and/or cause interoperability
> problems for consumers):
>
> - no profile URI present (can only be a warning once we, you know,
> define a profile URI)
>
> - property with empty value (that does not match one of the
> error-producing rules above)
>
> 
>
> - subproperty out of its proper container
>
> Mark
>
> - type with no value (this may be an error, I can't tell)
>
>  class="type">home: +1.415.555.1212
>
> - type with a value not defined in RFC 2426 (it is not clear from
> section 3.2.1 whether this is an error)
>
>  title="foo">my new adr type
>
> - geo information with latitude but not longitude (or vice-versa)
>
>  class="latitude">37.386013
>
> --
> Cheers,
> -Mark
> ___
> 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

[uf-discuss] RDFa

[Ben Ward]

A W3C Working Draft published on May 16th:
http://www.w3.org/TR/2006/WD-xhtml-rdfa-primer-20060516/

For Embedding RDF in XHTML. Gives iCal and vCard examples. In  
practice, there's a bit mark-up involved than with µF (namespace  
declarations for a start) but seems to acheive much the same thing in  
the end.


One interesting thing to note is the use of the META element for  
embedding computer-readible data, e.g.


May 8th at  
10am


Has this ever been considered for Microformats? It seems especially  
relevant given the recent uncertainty regarding ABBR/@TITLE and  
accessibility tools. I have to admit, I've never seen META used  
outside the HEAD and never even considered it as valid. Could it be a  
viable alternative (if it's considered that an alternative is ever  
needed).


Regards,

Ben

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

Re: [uf-discuss] Addressing bits of information

[Ben Ward]

Tantek Çelik wrote:

But discussions of extending URL/URI semantics for addressing bits of
information?  I'm not sure that actually has much bearing on parsing
microformats.  But like I said, perhaps I am missing something.



I don't know if my interpretation brings this on topic or just clarifies 
(or confuses…) but the problem as I understand it, is exemplified like so:


I have a page listing 12 events using hCalendar. None of the hevent 
nodes have an ID and therefore cannot be referenced through fragments. 
However, I want to pass one of these events to a web service (say a 
Technorati pipe to generate an ICS file for the specific event). There's 
no way to do that.


Same thing with a page containing multiple hCards.

However, I honestly think that this problem is best solved by 
emphasising the need/benefit of putting IDs on vcard/vevent nodes, 
rather than inventing/adopting something more complex. Personally, I 
wouldn't think it unreasonable to have 'microformats must have an ID' as 
part of each spec.


I don't think we should overcomplicate the issue with talk of technology 
like XPointer or Selectors which are unimplemented in the areas needed 
to 'fix' this.


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

Re: [uf-discuss] RDFa and microformats

[Ben Ward]

Hi Evan,

RDFa was discussed a week or so ago on this list, and dismissed as  
off-topic for this list for a number of very clear reason. You can  
find the discussion in the uf-discuss archives here: http:// 
microformats.org/discuss/mail/microformats-discuss/2006-May/004142.html


The posts you really want to read are those from Tantek Çelik  
(namely: http://microformats.org/discuss/mail/microformats-discuss/ 
2006-May/004144.html). That should answer the questions you've posed.


Regards,
Ben

On 30 May 2006, at 16:30, Evan Prodromou wrote:


Hi, all. My name is Evan Prodromou, and I'm a web developer. I founded
Wikitravel (http://wikitravel.org/ ) and I'm also a developer on
MediaWiki (http://www.mediawiki.org/ ), the software that runs
Wikipedia.

I'm very interested in embedding semantic data into XHTML pages, and
implementing microformats is a big part of my dev work for Wikitravel
and MW. However, I'm concerned about the future of the project and  
it's

incompatibility with RDFa (http://www.w3.org/TR/xhtml-rdfa-primer/ ),
the W3C plan for embedding RDF in XHTML.

I'd like to know what the plan is for dealing with this  
incompatibility.

Ignore RDFa? Hope it goes away? Compete in the marketplace of ideas?

I've written an essay on the topic, which you can see here:
http://evan.prodromou.name/RDFa_vs_microformats
Note that this is my opinion only, not that of my employers nor of the
MediaWiki development group.

Thanks for your time,

~Evan


__ 
__


Evan Prodromou <[EMAIL PROTECTED]>
http://evan.prodromou.name/
___
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

[uf-discuss] More Microformats Browser UI

[Ben Ward]

Chris Messina wrote:
> Beautiful:
> 
http://www.hicksdesign.co.uk/journal/a-proposal-for-a-safari-microformats-plugin 


>
Well, I saw Jon's post it this morning let out an involuntary 
cry/laugh/choke kind of reaction. I demo'd a terrifyingly similar 
concept to Tantek on Saturday [EMAIL PROTECTED] (whilst stealing his nachos, 
naturally). It's my bad for not posting weeks ago of course, but… wow. 
Similarity is proof of a good idea I hope.


With thanks to Jon for the unintended kick up the arse to finish my 
write-up, I've finally published my interpretation of what is really a 
very similar idea: http://ben-ward.co.uk/journal/microformats-ui/


It's under a Creative Commons Attr+SA license, but as it says in the 
post if you want to implement it and can't meet the SA part for 
commercial reasons I'll happily relicense. The intention is just to 
encourage public evolution of the ideas.


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

[uf-discuss] hResume Check Please

[Ben Ward]

Hi all,

Since hResume is only a draft and there's not much in the way of  
automated checking,  I wonder if some of you could give my  
hResumified CV a look over. http://ben-ward.co.uk/cv


For general feedback, I quite enjoyed updating the CV to support  
hResume. For the most part the plain-HTML version I had before mapped  
very quickly to the µf, I had to add a few  for hevent  
structure, but that was all very logical so I'm pleased there.


A few frustrations/issues:

First up, the best-practice method of containing hCard within an  
ADDRESS element appears hard to implement, given the inline nature of  
ADDRESS. In my case, I tried to have [div#benmichaelward] (line 100)  
as an ADDRESS, but the block-level children triggers quirks mode in  
browsers and causes the block level content (h1, ul, dl) to become  
siblings in the DOM, not children, which in turn breaks stlyling.


Second, I find the mark-up required for skills - using rel=tag - to  
be rather laborious to author. I appreciate the value of using tags,  
pointing multiple skill sets to the same place, but there is a lot of  
typing involved, not to mention the effort of hunting out the URLs. I  
honestly don't know if there's a better way though, since everything  
I keep half-thinking of as I type this doesn't actually help very  
much (briefly the idea of a base URL for tags, but that doesn't  
actually get around much of the labour problem).


Anyway, I felt that worth flagging up in case anyone was sitting on  
an ingenious idea of a tag shorthand and needed motivation to post it.


The last thing regards experience/education hevents that are still  
ongoing (“2002-present”). Is it safe to assume, or should it perhaps  
be specified in hResume itself, that ‘present’ is implied by the  
absence of a dtend field?


Mark-up pedantry greatly appreciated.

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

Re: [uf-discuss] Currency microformat

[Ben Ward]

On 18 Jul 2006, at 07:24, Ben Buchanan wrote:

The classic problem example would be a page stating a price of "$50".
Is that Australian dollars? US dollars? Monopoly money? :)

This is certainly a worthy cause, but to play devil's advocate for a  
moment, could pure HTML be sufficient?



My new T-Shirts cost £30, but it cost my friend in Canada lang="en-ca">$34



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

Re: [uf-discuss] Currency microformat

[Ben Ward]

On 20 Jul 2006, at 07:27, Ben Buchanan wrote:


So... I think $50 would work as a  
shorthand.


It defines
a) we're talking about money - ISO standard implied,
b) we're talking about the USD variety,
c) we're talking fifty units of that money,
d) a parser could work out the numbers and the symbol.

Of course you could use ABBR instead of DIV.


The problem of having the ‘USD’ inside a class attribute is that this  
hides the data from humans. I think that for the above mark-up, the  
USD portion does need to be part of an ABBR/@title. Bt of course,  
$50 is arguably inaccurate,  
since the @title should probably read ‘50 USD’, not just ‘USD’.


At that point it actually makes is clearer to me the fact that we're  
marking up numbers and units, not just currency. It leads on to mark- 
up like this:


£abbr>50

25cm

I've left the ‘currency’ class name in addition to ‘unit’. It felt  
intuitive as I wrote it. Whether any provisional ‘units of  
measurement’ µƒ matching the above should have an enumeration for  
such values: currency, distance… not sure. Go too far down that road  
and suddenly you're looking at a µf or specifying dimensions* instead.


Ben

(* To go entirely off on a tangent, a common way of describing  
dimensions, built on top of some sort of units µf actually sounds  
quite useful in my head: Visit IKEA, view a table and click a button  
to have a block representation of that table imported Google SketchUp  
or some sort of interior design application… Now perhaps it's just  
the lack of early morning coffee but that sounds alarmingly viable  
and certainly makes me feel that a units µf could be a very useful  
foundation to have)

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

Re: [uf-discuss] origin of class attribute approach in microformats ?

[Ben Ward]

On 22 Jul 2006, at 03:15, Tantek Çelik wrote:

should these all be in the FAQ?


I think we should definitely have this covered on the Wiki; it seems  
in the same spirit as dispelling the /. misconceptions last week.  
Definitely worth getting this documented definitively, 'cause it  
seems to be a very common misconception.


Ben

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

Re: [uf-discuss] Media Metadata, Specifically Video Thumbnails

[Ben Ward]

On 16 Aug 2006, at 22:46, Steve Williams wrote:
I don't want to do something that might influence a bunch of sites  
if it would hurt the Microformats effort.


I wouldn't be too worried about that. The Microformats process  
(http://microformats.org/wiki/process)  says that µf are built  
wherever possible on _existing_ behaviour.


So what you need to look for is whether other sites that use  
thumbnails for images or video are using a reproducing scheme. As  
Charles says, class=thumbnail is common and has been discussed before  
somewhere.


However, if evidence is in short supply, your best move is to think  
carefully about what information Digg needs to glean from pages  
(video format and identification of thumbnail images have been  
identified in this thread so far, but you may have other  
requirements: captions? titles? copyright?) and then work out the  
best scheme in HTML you can. It wouldn't be a microformat in an  
official sense but it would be evidence towards building one in the  
future (especially on a site as big as Digg).


I'm sure there are lots of very wise and knowledgeable people here  
who'd be happy to provide input if you were to draft such a scheme,  
although I'm not 100% sure if that would be on-topic.


Also try to think within the bounds of raw HTML. Can the thumbnail  
‘functionality’ you desire be achieved without any class name  
additions? What about an IMG, nested within an A that links to a  
video file? Is that sufficient? (from a few seconds thought it isn't,  
since it could be an image as part of navigation, not a thumbnail at  
all, but it's the principal I'm trying to demonstrate).


Best of luck,

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

Re: [uf-discuss] Media Metadata, Specifically Video Thumbnails

[Ben Ward]

On 16 Aug 2006, at 23:23, Steve Williams wrote:

I'd think you'd need something more like  ...


I thought of that, and I like it a lot.  Is that a common pattern  
in new microformat proposals?


@rel gets a lot of use where appropriate. The only thing here is that  
you must remember the rel refers to the _page_ the link exists on,  
not necessarily a part of media within that page. Although, I believe  
xFolk limits to scope of rel-tag, so perhaps there's a precedent for  
extending its use.


If scope limiting rel and rev is appropriate here, I think that that  
something like this would be valid:


src="thumb.png" alt="…"/>


@rev in this case indicating the current page/fragment (indicated by  
rev-thumbnail) is a thumbnail for the page being linked to.  
Remembering that rel describes the relationship between the link and  
the current page (e.g rel-stylesheet says the linked document is a  
stylesheet FOR the current page), rev describes the reversed  
relationship of current page for the link.


In this case, you're additionally specifying the IMG child of a rev- 
thumbnail link is the thumbnail for the content of the linked page.


… I think that's right anyway. Rev does make me think at this time of  
night!


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

Re: [uf-discuss] does hatom for comments make sense?

[Ben Ward]

On 11 Sep 2006, at 23:17, Stephanie Booth (bunny) wrote:

Does this way of using hatom on comments make sense to you?


It does to me, yes. Although not using two separate hAtom feeds. I'd  
just have one with the original post as the first entry in the feed  
and comments following on sequentially. It's _a feed of the  
discussion_, in my eyes.


I'm not sure I understand the reason for wanting multiple feeds or  
nested feeds to represent comments. I can't see the need for a  
distinction between a comment and the original post at all.


The most important thing, with regards to the Atom 1.0 spec, is that  
the id for the original post in the comments feed should be the same  
as the id for that same post in the main, front-page feed. If a  
conforming feed reader were to subscribe to both feeds, it should  
understand that they are the same entry.


Ben

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

Re: [uf-discuss] a very early draft proposal hTagcloud

[Ben Ward]

On 19 Sep 2006, at 21:08, Stephen Paul Weber wrote:

rel=tag do the trick?


The semantics of Rel-Tag would apply the tag to the current page,  
which wouldn't be correct. In the case of a tag cloud you're just  
linking to the tag pages, not indicating a relationship between the  
tag(s) and the tag cloud page itself.


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

Re: [uf-discuss] a very early draft proposal hTagcloud

[Ben Ward]

On 20 Sep 2006, at 02:23, Chris Messina wrote:

I think what you need to define are ways to express relativety -- and
that , ,  and  can help in indicating those
relationships with styles turned off. So for example, the very
smallest size might always have  surrounding the  tags...
so that there's a lower limit. You could use  or  around
the  tags to express the upper limit.


I'm not sure about using BIG and SMALL. We start getting into the  
territory of redefining elements (adding semantic values to those  
presentational elements[1]) which is something the WHATWG are already  
doing with HTML5. Mainly, they're redefining SMALL for ‘small print’  
in documents [2], which conflicts directly with using SMALL in tag  
clouds.


Personally I quite like the nested behaviour. I accept that is also  
unspecified implied semantics, but it doesn't seem unreasonable… that  
said, you can get four levels of tag cloud without nesting of the  
same element (by using STRONG as well), e.g:



  A Level One
  B Level One
  C Level Two
  D Level Three
  E Level Four
  F Level Three
  Level One


Would four levels be enough?

Ben

[1] http://www.w3.org/TR/REC-html40/present/graphics.html#h-15.2.1
[2] 
http://whatwg.org/specs/web-apps/current-work/#the-small___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] a very early draft proposal hTagcloud

[Ben Ward]

On 20 Sep 2006, at 10:45, Matthew Levine wrote:
However, I'm not whether I like exploiting nesting order. It feels  
a bit hackish, and isn't as semantically unambiguous as Ben's  
initial example.


Yeah, I considered EM > STRONG and STRONG > EM as well but as you  
say, it's very hackish and in my interpretation of the semantics I  
come to one of two conclusions:


* Either EM > STRONG and STRONG > EM are equal, so couldn't represent  
different levels

or
* EM > STRONG is semantically invalid as ‘Strong emphasis’ is greater  
than ‘Emphasis’. It seems very wrong that EM can be the parent of  
another element which describes a larger, bigger application of the  
same semantic… unless we were to make EM inherit semantics from the  
little known TARDIS element.


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

Re: [uf-discuss] Use of (also ) and Accessibility

[Ben Ward]

On 21 Sep 2006, at 20:05, Andy Mabbett wrote:
There're some interesting views about the use of  by  
microformats,

on the Accessify forum:



also an interesting take on the non-use of .


I'm a little confused reading through that: The debate about whether  
the use of ABBR is fine and well, I follow that, but maybe I came too  
late the Microformats community to understand the references to OBJECT.


I was under the impression that the OBJECT bugs in Safari were  
related to the first generation include pattern, prompting the  
creation of rel-include. Can someone link me to a post in the  
archives that concerns the OBJECT and ABBR for datetimes issue the  
Accessify thread raises?


In general, the _theoretical_ ABBR discussion is well based, datetime  
is a new use and perhaps it stretches the element too far…  maybe  
not. The thing is though, people love to talk their interpretation of  
the semantics and expected behaviours but I'm yet to see anyone with  
access to assistive technology produce examples to demonstrate  
problems (or otherwise).


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

Re: [uf-discuss] basic include pattern question

[Ben Ward]

On 22 Sep 2006, at 02:26, Michael McCracken wrote:

Should
I just repeat the info that I want displayed?


Yes. The include pattern (both the OBJECT and rel-include variants)  
allows you to point a microformat to some other piece of data  
published already in the page, for the purpose of *not* repeating  
information. So for example, I could fix up my website with hAtom for  
blog entries, and rather than repeat my hCard in every entry, just  
use the include pattern to point to the fulll hCard in my sidebar  
each time (although hAtom has handling for that anyway, so that  
example is slightly mute).


Anyway, in situations where you want information to be included and  
displayed in the page it should be written directly as content. The  
include patterns in µf are for parsing when you *don't* want to  
display repeated data.


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

Re: [uf-discuss] Microformat's Logos

[Ben Ward]

On 26 Sep 2006, at 10:13, Simone Onofri wrote:

On the left we can insert the Mf logo and on the right, with a pixel
font, with hCalendar, hCards So, I can create it. What formats do
You want?

Aha, that's kinda my point. I question the usefulness of putting a  
microformats logo on a page with ‘hSomething’ text next to it. What  
does that mean to visitors? Admittedly not a lot less than putting  
‘XHTML’ and ‘CSS’ in a pretty box, but for users, it surely makes  
more sense to refer to _Contacts_ and _Events_ respectively, since  
that is the data they're working with.


I mean that in a general way: Naturally from the point of view of  
people involved in the microformats community looking to promote the  
microformats themselves then certainly using the name and logo makes  
sense but using the ‘technical term’ to indicate the presence of  
microformat on a page to _end users _ seems like a bad idea.


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

Re: [uf-discuss] Microformat's Logos

[Ben Ward]

On 26 Sep 2006, at 01:13, Stephen Paul Weber wrote:

Hello,
  I was wondering if there had every been any serious thought to
giving individual microformats logos (for widgets and buttons and
such, etc).


I'm not sure whether it counts as serious thought, but the issue of  
icons for hCard and hCalendar came up when I published my µf UI  
mockup a few months back [1]. I took that the view that in the case  
of hC* it makes most sense for them to adopt icons akin to their  
desktop cousins: Namely contact cards and calendar appointment icons.


Generally speaking, I'm anti creating dedicated icons for  
Microformats since the whole point is not that they _are  
microformats_ the point is the _data_ and the purpose of that data.  
Take Tails as an example, rather than show the µf logo in the Firefox  
status bar, I'd rather like it to show icons related to the type of  
microformat found (again, akin to my mock-up).


hAtom? It's a feed format so should really be indicated with the  
standard feed icon (although I did once create something utterly  
different [2]).


The other formats, be they new concepts (hResume) or just never  
iconified before (xFolk) seem well worth thinking about though.



I created an XOXO logo back when I started the XOXO Blog
.  An
aquaintance recently told me that it was rather ugly and decided he
would try his hand,


Depending on how strongly people are disliking OPML this morning  
(;-)), there is an apparent effort to create a ‘standard OPML  
icon’ [3] . If there's a need, that could possibly be persuaded into  
becoming a ‘standard outline icon’? Depending on whether they're  
prepared to open their scope at all, or whether their aim is to  
promote OPML exclusively.



but of course any of these efforts is far from
'official'.


Well, I never saw if the Microformats Community accepted the idea,  
but Chris Messina has been pushing for the logo to be covered and  
protected under a ‘community mark’ concept where effectively group  
consensus determines acceptable use of the microformats logo. If  
that's actually been adopted here then I would suspect that icons for  
individual formats would be ‘official’ when taken under the same  
community protection.


Ben

[1] http://ben-ward.co.uk/journal/microformats-ui/
[2] http://flickr.com/photos/benward/106037547/
[3] http://www.opmlicons.com/


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

Re: [uf-discuss] hidden microformats

[Ben Ward]

On 28 Sep 2006, at 01:15, Paolo Negri wrote:

On some pages I have all the infos about these items and I can produce
very complete uformats. On other pages I render let's say just the
name and the email of someone and it doesn't make sense to provide a
less complete hcard than in a different page, and I absolutely can't
add the extra information (address, role) as visible.


Perhaps the better solution for this would be to revive (and perhaps  
conclude) the ‘linking to a definitive microformat’ idea which has  
popped up every so often. In short, provide a rel value to contain  
within an hCard or hEvent which links to the page with the full  
information. Parsers are then instructed to follow that link where  
appropriate to get complete information.


That's still a work-in-progress though, so my advice for now is that  
as Ernie Prabhaker says, there's nothing wrong with having smaller,  
less complete hEvents, they're still valid microformats. For now,  
just make sure you're linking to the full page from them and if in  
the near future a suitable rel value is designed to parse those  
links, you can add it in with no destruction or reworking required in  
your application.


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

[uf-discuss] Microformats in Form Fields

[Ben Ward]

Hello list, just a quick point for discussion:

Lets say you have a personal registration form in your web app, for  
entering contact data which will later be output as an hCard in  
various places.


What if I was to mark up the form (and fields) with hCard classes?  
Good idea? Bad idea? I strikes me that it could be useful for auto- 
complete applications, but not sure if it would ‘pollute’ the web  
with effectively a useless/empty hCard when the form is published.


Opinions?

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

Re: [uf-discuss] Microformats in Form Fields

[Ben Ward]

Frances Berriman wrote:

Did
you see Drews demo of that with openID?  It didn't require the forms
to use the microformat class names or anything.


Yeah, I've seen Drew's excellent auto-fill demo and had a couple of  
conversations with him about combining that with OpenID. This isn't  
so much about providing my own custom µf autofill as part of the web  
app (yet ;-) ), which would of course understand my bespoke form  
arrangement. It's more about putting the classnames in place that a  
separate tool, browser or bookmarklet could provide a more accurate/ 
powerful autofill than the guesswork based autofills we have at the  
moment.


On 28 Sep 2006, at 12:53, Ciaran McNulty wrote:

The problem is that under most uF parsing rules,  elements'
@value will not be used to determine their content.  However, a
 would be parsable as you'd expect.


That could be resolved by adding a new design pattern for input  
elements.


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

Re: [uf-discuss] Microformats in Form Fields

[Ben Ward]

On 28 Sep 2006, at 13:33, Stephen Paul Weber wrote:

What about using the same markup as the appropriate uF, but a
different root class name (such as 'form')?


That's a possibility I guess, but thinking for a moment in the  
context of the DOM, with the form fields filled in (and an  
appropriate parsing rule for  reading values from form fields) you  
have a valid hCard/hEvent…


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

Re: [uf-discuss] Microformats in Form Fields

[Ben Ward]

On 4 Oct 2006, at 19:37, Scott Reynen wrote:
What is the benefit of using the same root class name for forms  
accepting a microformat as we use for the published microformat?


The first that comes to mind: If the form is pre-filled then you have  
a valid vcard that could be parsed (with the addition of some form  
parsing rules). Take for example an ‘Edit Profile’ page that contains  
existing values.


Whether that falls outside 80/20 I'm not 
sure.___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Advanced include pattern usage

[Ben Ward]

Good morning List,

I have a quick question about include pattern usage and visible data.  
A while ago I was playing around with drafting something for the  
hChatLog effort (I haven't got anywhere yet, really) but will use it  
as an example, since I think the use of include-pattern is nicely  
demonstrated here:



  Ben Ward
  href="http://nascentguruism.com";>Steve Marshall


 
  
Ben Ward
Good morning, Steve
  
  
Steve Marshalla>

Mornin’
  



So what's happening here is that full hCards are declared at the top  
of the page, and then referenced in each message to avoid repetition,  
as is the purpose of the include-pattern. However, because we don't  
want the vcard to be completely invisible and do want the person's  
name to be read as part of the content, the innerText/nodeValue of  
the A/@class=include element contains text.


So in the context of a Microformats parser the hCards should be  
included, and should replace the innerText.


This is obviously going beyond the original idea for the anchor-based  
include pattern, but is actually a benefit of the A-based pattern  
over OBJECT. Is it a valid use? Should it be documented as part of  
the include pattern?


Regards,

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

Re: [uf-discuss] Advanced include pattern usage

[Ben Ward]

On 23 Oct 2006, at 13:36, Brian Suda wrote:

 I'm not sure exactly what you mean by
should it be documented, maybe we are talking about two different
things? There is a section about using the 'a' element.
http://microformats.org/wiki/include-pattern#hyperlink_include_example
If it is unclear and there needs to be a better explaination,
examples, etc, please let us know.


The existing example documents use of an _empty_ A element as a  
marker for content to be included. In my example above, the A element  
is not empty and I'm expecting a parser to *replace* my inner text  
with the included element.


I guess it's the latter, ‘replacement’ behaviour that could be need  
to be explicit or exemplified, although re-reading I note that the  
OBJECT pattern above includes the sentence “the object include  
completely replaced by the subtree that it references”, which may be  
sufficient in the context of that page.


Thanks very much for the clarification Brian.

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

Re: [uf-discuss] Advanced include pattern usage

[Ben Ward]

On 24 Oct 2006, at 11:13, Colin Barrett wrote:


Your example looks quite nice! As someone chiefly interested in  
hChat, I'd like it if you could put your work on the wiki. It  
hasn't been updated in a about a month.


-Colin


Colin, I intend to. I've had a file named ‘hLog Draft’ sitting on my  
desktop for too long now. I'll have a crack at documenting it as a  
straw man proposal, along with a few contentious issues, tonight.  
Thanks for the prod :-)


I've added a couple of additional references to dialogue mark-up  
discussion to the Brainstorming page.


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

Re: [uf-discuss] Visible Data...a Microformat requirement?

[Ben Ward]

On 26 Oct 2006, at 18:35, Colin Barrett wrote:

On Oct 26, 2006, at 7:25 AM, Andy Mabbett wrote:

In message
<[EMAIL PROTECTED]>, Ciaran
McNulty <[EMAIL PROTECTED]> writes

@rel=bookmark
I've seen several people refer to such things with an opening "@"  
- what

does it mean?
I'm not sure on the etymology, but they're referring to attributes  
on (X)HTML tags.


It's a lazy XPath-ish syntax that a has slipped into the geek  
vocabulary (much as CSS selectors are sometimes used to quickly  
describe a structure of elements).


@ represents an attribute, so @rel=tag means @rel tag with the value  
‘tag’. The most advanced I've seen it get in general discussion is of  
the form [EMAIL PROTECTED], which means ‘element named foo with an  
attribute bar with value ‘sheep’.


If people object, it's probably unreasonable to ask us not to use  
such abbreviation, or preferably (for me at least, who likes to  
abbreviate like that) perhaps we should document the shorthand on the  
Wiki?


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

Re: [uf-discuss] Visible Data...a Microformat requirement?

[Ben Ward]

I just wrote:
> If people object, it's probably unreasonable
>
When of course I mean ‘not unreasonable’.

and:

> @ represents an attribute, so @rel=tag means @rel tag with the value
> ‘tag’
>
@ represents an attribute, so @rel=tag means the attribute rel with  
the value 'tag'.


My mind is frazzled.r Apologies.___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Visible Data...a Microformat requirement?

[Ben Ward]

On 27 Oct 2006, at 00:58, Colin Barrett wrote:

@ represents an attribute, so @rel=tag means @rel tag with the  
value ‘tag’. The most advanced I've seen it get in general  
discussion is of the form [EMAIL PROTECTED], which means ‘element  
named foo with an attribute bar with value ‘sheep’.


Technically, in CSS, that would be written as foo[bar=sheep]. :P


Indeed, although in XPath [EMAIL PROTECTED] is correct. Actually, you  
raise a good example since CSS allows you to say foo[bar~=sheep],  
(note the tilda), which is correct for matching the substring  
contents of string separated list attributes like class and rel.


I will be happy to chip in on documenting this in the Wiki, but my  
todo list is really busy so I might not get round to writing  
something of any quality for too long. If someone else is able to  
start it I'll try and chip in.


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

Re: [uf-discuss] Apple adds support for hcard in dotmac webmail

[Ben Ward]

On 29 Oct 2006, at 21:45, Chris Messina wrote:


if only URLs could be turned into IDs:


Not sure what your intention would be Chris, but there's a fairly  
well established practice of converting 'http://microformats.org/ 
something.html to the form 'microformats-org-something-html' for page- 
unique BODY element IDs. Would that suffice?


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

Re: [uf-discuss] Internet Explorer 8.0 will support microformats

[Ben Ward]

On 30 Oct 2006, at 13:48, Mike Schinkel wrote:

I've got a question about this.  To say IE8 will support Microsformats
doesn't make sense to me, unless they means it will support the  
Microformats
agreed to at the point IE8 is made feature complete.  But what  
about those

that come after?


With no first-hand announcement I can't be entirely sure, but I  
suspect what Chris means is ‘IE8 will support _some_ Microformats’.  
E.g. it might have automatic handling of hCard and hCalendar entries  
for clipboard functionality and integration/subscription in Windows  
Vista's new Contacts manager and Windows Calendar.


Ben

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

Re: [uf-discuss] vote-for

[Ben Ward]

On 6 Nov 2006, at 21:25, Siegfried Gipp wrote:
Indeed, this i do not understand.Why should a definition of  
rel="vote-for"

have any negative effect (or any effect at all) on the definition of
rev="vote-for"? These are two different attributes.


It's because the microformat does not define the meaning of  
'@rel=vote-for', it just defines the meaning of 'vote-for'. The rel  
(or rev) relationship comes direct from HTML. The pool of values for  
@rel and @rev are shared as they are closely related attributes by  
design (these values are not always appropriate in both directions,  
of course).


So, the value 'vote-for' is definable as 'a positive vote for a  
resource'. That's what vote-for (and vote-against and vote-abstain  
with their respective definitions) *always* means when used in HTML.  
The source and target of that relationship is what the @rel and @rev  
attributes describe, not 'vote-for' itself, and that comes from HTML.


Hope that clarifies.

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

Re: [uf-discuss] Microformats support in Flickr

[Ben Ward]

On 7 Nov 2006, at 13:25, Goix Laurent Walter wrote:
I have tried to put some hCard in the description field of some  
picture to include the name of the people in the pic, as well as  
the address where the picture was taken, but each time the HTML was  
somehow modified by Flickr at the time of saving and microformats  
were removed...


If I remember correctly, Flickr strips the @class attribute from HTML  
you input, making it microformats unfriendly. The only 'supported'  
way to indicate people in photos is through tags.


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

Re: [uf-discuss] vote-for

[Ben Ward]

On 7 Nov 2006, at 17:03, Ciaran McNulty wrote:

that makes rel="vote-for" mean "This url is a vote for the
current page".


Correct. However, this isn't mentioned in the spec or anywhere  
because it has an issue with authority.


I could say 'That page over there is a vote for me'. That isn't  
authoritative, I could say that Google, Technorati, Tantek and  
Siegfrief Gipp all voted for my resource but an application shouldn't  
use that data, since I could be lying about it.


Now you could still do this, but an application would have to inspect  
each of those resources to make sure the votes were really valid.


Of course, that's still a valid use and does have assistive value to  
applications, but the authoritative relationship of vote-* is still  
@rev. That's why the spec talks in terms of @rev.


Now, that's not to say the Wiki couldn't be expanded to describe what  
I've just said (but, y'know, better), but it certainly _is_ to say  
you cannot take @rel=vote-* to mean anything but the opposite of  
@rev=vote-*.


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

Re: [uf-discuss] class="url"?

[Ben Ward]

On 7 Nov 2006, at 17:39, Tantek Çelik wrote:

So if to apply the class="url" to one of them,
this means selecting that very special url to be the url for the  
VCARD URL


Applying class="url" means selecting that "very special" URL to be  
*a* URL

for the hCard.

Please re-read what I wrote above.  *A* URL.  There is no assertion of
uniqueness ("the").

Indeed. Siegfried, note that many address book applications (and some  
Microformats parsers) do allow multiple URLs in a VCard. In such a  
case, ALL those URLs in the hCard mark-up will have @class*=url.





then this microformats word "url" does not have
exactly the same semantics as the word "url" defined by the w3c.


No, the microformat class name "url" has the semantics of the "url"  
property
as defined in vCard and iCalendar.  See the hCard profile which  
defines the

class name "url": http://microformats.org/wiki/hcard-profile



I must concede, I find this part of the discussion very confusing. As  
best I can tell, we're discussion two completely different contexts  
of the word 'URL' here. One is the definition and specification of  
URLs is, the other is the use of the word URL to relate a URL  
contained in the @href attribute, to a defined property.


I don't see why the definition of one should be expected to affect  
the definition the other?


Ben


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

Re: [uf-discuss] hCard - Telephone types (cell, office etc)

[Ben Ward]

On 14 Nov 2006, at 15:48, Ian Lloyd wrote:
I've had issues where by placing the Work  
in the HTML, it imports that information into the hCard itself, so  
that in iCal on Mac it shows as :


Cell: Mobile +44 (0) 7710 623044


I may also be suffering from end-of-day fatigue, but from your mark- 
up that should work as expected, given that you've specified type and  
value. So I'm inclined to cry parser error at this point.


Have you tried it with a number of different µf parsers to see if  
they all suffer the same bug? For example, Suda.co.uk and Technorati  
are often out of sync in their XSLT so one may have the bug and one  
may not, and the Microformats Bookmarklet [1] I think does it all  
differently using JQuery and could produce a different export result.


That's if it's a parser error at all, but I can't see the error on  
your side if it's there.


[1] http://leftlogic.com/info/articles/microformats_bookmarklet

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

Re: [uf-discuss] Contextual link information using microformats

[Ben Ward]

On 17 Nov 2006, at 18:45, Andy Mabbett wrote:

hreflang="en"
type="application/pdf"

I wonder how widely used those two are, in real life?


I'd suggest that hreflang is close to minimal, not least because  
there's an assumed (though probably not specified) implication that  
link targets are going to be in the same language as the source page.  
I imagine if cross-language document linking were more commonplace  
there would be more interest and knowledge in @hreflang.


@type is increasingly used and useful though. Auto-discovery  
mechanisms use type="application/rss+xml" and "application/atom+xml"  
to recognise XML feeds.


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

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Ben Ward]

On 5 Dec 2006, at 11:30, Mike Schinkel wrote:

For those on this list who are not following [whatwg], here is an
interesting thread about inability to use Microformats:

http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006- 
December/00

8462.html

I wonder if his issues can be addressed?


I'm not sure if they can, or not here at least. What I get from his  
message is not a problem with any specific Microformat, but that IBM  
finds the class/rel/rev/profile extension mechanism of HTML too  
limiting for their needs.


In particular, he gives an example of ‘customers submitting their own  
microformats’, which is not the same as what we refer to as  
‘microformats’ at all. In fact, such broad user-defined formats  
sounds distinctly out-of-scope of our efforts.


If handling a large number of discrete user submitted bespoke formats  
is IBM's goal on their project, it's comprehensible that the  
extension mechanisms in HTML probably are inappropriate. Therefore, I  
think they're taking the right path in asking the WHATWG for a more  
suitable mechanism for them and their goal, but it doesn't really  
expose any problems with well specified microformats here.


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

Re: professional relations (was: XFN usage stats and Re: [uf-discuss] rel="muse" implies romantic relationship?)

[Ben Ward]

On 12 Dec 2006, at 22:05, Andy Mabbett wrote:

Not to mention: mentor, mentee, trainer, trainee,


With a lot of these (I've personally been pondering ‘employee’ and  
‘employer’ of late)  the reverse is not required as a unique term,  
but can instead be put in the rev="" attribute of the link.


——
On SmallCompany.com

Employees

  http://ben-ward.co.uk";  
rev="employer">Ben



Corresponding on Ben-Ward.co.uk:

 … Small Company … 

——

I think there're some legs on the idea of XFN Professional additions.

Ben

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

Re: Microformats *do* seek to change behaviour (was: XFN usage stats and Re: [uf-discuss] rel="muse" implies romantic relationship?)

[Ben Ward]

On 13 Dec 2006, at 11:53, Ciaran McNulty wrote:

so my pages don't validate correctly if I add 


Actually, it's more severe than just not validating. Nesting block  
level elements within ADDRESS triggers error-handling in browsers,  
such that the DOM does not reflect your mark-up. Mark-up such as:


> ADDRESS
--> DIV
> UL
> P

Will make a DOM of:

> ADDRESS
> DIV
--> UL
--> P

Where DIV is a sibling of ADDRESS, not a child.

This affects parsing, styling and anything you like,  another reason  
ADDRESS is not required by any microformat.


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

Re: professional relations (was: XFN usage stats and Re: [uf-discuss] rel="muse" implies romantic relationship?)

[Ben Ward]

On 13 Dec 2006, at 18:29, Andy Mabbett wrote:

I thought "rev" was in the process of being deprecated?



I do hope not; I'm quite a fan of the little blighter. Do you have a  
URL for that?

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

Re: [uf-discuss] A microformat for relationship availability and preference?

[Ben Ward]

On 21 Dec 2006, at 10:10, Ciaran McNulty wrote:

Inherent in the Microformats movement is the desire to make
information easier to publish and aggregate, but people need to
consider carefully what parts they want to make available about
themselves and their relationships to others.

In my day job, I keep seeing places where an hCard would be useful
where organisations are publishing contact information, but far from
wanting to make it easily parsable they seem to put all their efforts
into trying to obfuscate it to avoid getting more spam!



With this issue, it makes no difference whether you publish  
microformats or not. Phone numbers and email addresses (even postal  
addresses) are all parsable without microformats — with sufficient  
effort and regular expression complexity.


Spammers will go to that effort; it's their business to gleen  
information to abuse. I'm sure they'd be delighted to find hCards to  
parse and make their lives a little easier, but I don't see that it  
gives them any information that they wouldn't have got otherwise,  
through other means.


As always, the only way to keep information private on the internet  
is not to publish it in the first place.


Ben

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

[uf-discuss] SPAN, DIV and Rich Examples

[Ben Ward]

’afternoon list,

A little while back I had a discussion with some people (Frances  
Berriman for one) about including a second set of ‘examples’ with the  
microformat specs. Dubbed ‘rich examples’ they would exist on a  
separate page to existing examples and showcase implementations of  
the microformat using varied, adventurous and ‘real world’ HTML mark-up.


At the moment, there is a common misconception that microformat  
classes must be applied to DIVs and SPANs. Some developers are  
resistant to adding these as additional elements to their mark-up.


Of course, the µf specs use SPAN and DIV to remain as ambiguous as  
possible; so as not to seemingly require certain semantic elements  
where any is applicable. It aids legibility and avoid readers  
thinking ‘but that example used a DFN and this one uses a P? What?’.  
Apart from microformats where a specific element _is_ required, of  
course (date-times and ABBR, XOXO, and so on).


So I'd like to propose two things. First, we make a new page for each  
implementable microformat: *-rich-examples. On these pages we create  
and document sets of examples that show microformats integrated into  
all kinds of different HTML structures: Lists, images, paragraphs,  
sidebars, footers and so on.


I think it's important to have them on a separate page as it will  
allow people writing their own examples in the wild to include a  
small link at the base of their piece akin to ‘You can use all kinds  
of mark-up with microformats, see the hCard Rich Examples page for  
all sorts of flexible examples’.


Second, to ensure the mis-interpretation regarding SPAN and DIV is  
thoroughly stubbed out I'd like to have a STRONGly emphasised  
paragraph added to the header of each spec. Effectively a disclaimer  
reading:


  ‘As you read the microformat specifications and examples,
  you'll find they  all use SPAN and DIV elements. This is for
  clarity and to help keep the focus on the class names being
  used. However, you should use the most semantic mark-up
  appropriate. To see how flexible microformats can be, see
  the Rich Examples page.’

Better wording of that paragraph would be appreciated!

Is there support for this idea? I'd like to see some consensus before  
making Wiki edits to major spec pages. Plus, the creation of rich- 
examples pages will need collaboration because I don't have enough  
hours to create many by myself.


Regards,

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

Re: [uf-discuss] SPAN, DIV and Rich Examples

[Ben Ward]

On 22 Dec 2006, at 17:08, Andy Mabbett wrote:

That sounds like a good idea; but I wonder if we should not break it
down further, and have each example on a separate page, not on the  
wiki,

but elsewhere, so they can be "viewed" using any of the available
parsers.


Not sure. I'd see the purpose of the page better served by being able  
to scroll through. There's an element of it being a source of  
inspiration and enlightenment, rather than a tutorial on each method.


As for parsing with tools: Presuming that our MediaWiki installation  
is capable of rendering the ABBR element — by default it gets  
stripped from mark-up — surely it would be sufficient to place an id  
on each rendered example? That would make each example addressable.



Better wording of that paragraph would be appreciated!

The examples on this page use span and div elements, for
clarity, but any HTML element can be used (though abbr is the
only one whose title is parsed).


Better, although I don't think it's the right place to refer to the  
intricacies of the ABBR pattern. That would be demonstrated in  
examples themselves. So how about:


  “The examples on this page and the *-examples page use
  SPAN and DIV elements for clarity. However, *any* HTML
  element can be used when publishing microformats.
  See *-rich-examples for more detail.”

(*-examples and *-rich-examples would link to the appropriate pages,  
of course).


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

Re: [uf-discuss] Useful to have multiple links that provide the same tag?

[Ben Ward]

On 24 Dec 2006, at 14:04, Costello, Roger L. wrote:
http://en.wikipedia.org/wiki/juicer"; rel="tag">Wikipedia  
entry

for juicer

http://www.technorati.com/tag/juicer"; rel="tag">Other web
pages with a juicer tag

http://www.xfront.com/juicer"; rel="tag">Costello's pithy web
page on juicers

Would it be meaningful to put all three links into my web page, i.e.,
tag my web page three times with the same tag?


I believe that the uniqueness of the ‘tag’ is the URL. So what you've  
got there are three different tags. The URLs they link to can be used  
to disambiguate the meaning (less so with ‘juicer’, but with other  
tags like ‘windows’ linking to the Wikipedia article on the Microsoft  
Windows operating system will disambiguate from the kind that I'm  
looking out of and from the GUI concept that I'm typing into.)


So yes, you can provide meaning because linking to certain tag spaces  
can disambiguate. Whether that's useful for every tag or not is  
debatable though and probably comes down to personal preference and  
whether you think it will be useful for the users of your particular  
site to be linked to aggregators like Technorati.

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

[uf-discuss] Tagging Tag-spaces

[Ben Ward]

On my blog, all tagged entries link to my own local tag-space (e.g. / 
journal/tags/nutcracker). What if, on the page for each tags, I were  
to include:


http://technorati.com/tags/nutcracker"; rel="tag">…
http://en.wikipedia.org/wiki/nutcracker"; rel="tag">…

So my tag space is now itself tagged with the same tag name on two  
external resources. Does this mean anything?


Should this mean something to the entries tagged with ‘nutcracker’ in  
my blog itself? Could it be used to provide a disambiguated context  
to the tags used on a site of limited scope. For example, limiting  
the tag ‘Mac’ to raincoats — not to Apple's computer — by linking to  
the appropriate Wikipedia entry from my own /tags/mac page?


Ben


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

Re: [uf-discuss] Merry Christmas

[Ben Ward]

On 24 Dec 2006, at 17:04, Andy Mabbett wrote:
I'm just about to unplug my PC for the holiday, but first I wanted  
to wish you all a very Merry Christmas.




Unplug? What is this disconnection you speak of? Next thing you'll be  
telling me there's an off button…


Merry Christmas, all.

Ben

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

Re: [uf-discuss] rel="pavatar"

[Ben Ward]

<[EMAIL PROTECTED]> wrote:

Is there no interrest in such a microformat like rel="pavatar"?

 /Jeena


Without getting into the technicalities of ‘what makes a microformat’  
at this stage, I think another reason for lack of interest is that  
really, the hCard microformat can already provide the same function.


The ‘logo’ property of hCard [1] is already used in the wild (to what  
degree I can't say) to mark up ‘avatar’ images.


So for example:

http://example.com/pic.png"; rel="pavatar">

Can be represented within an hCard:


Ben Ward
http://example.com/pic.png"; alt="" />


Therefore, I think that demand for your pavatar specification is  
limited here as there is in effect an existing solution, which goes  
further than pavatar by making the image a visible part of the  
content as well.


It doesn't have the additional restrictions you impose, of course  
(the 80 pixel square requirement) but there's nothing to stop you  
layering policies like that over hCard when implementing.


Regards,

Ben

[1] http://microformats.org/wiki/hcard- 
examples#3.5.3_LOGO_Type_Definition

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

[uf-discuss] What is ‘post-office-box’?

[Ben Ward]

Just a quick one.

VCard defines ‘post office box’ as part of ADR. The spec [1] says  
that it comes before ‘extended address’ in sequence, but then fails  
to provide an example for it. As such hcard-examples also doesn't  
provide an example.


What's the expected content in this field? Is it literally as-in some  
UK addresses?


*PO Box 5674*
Enfield
London
SW2 1FE

Or is it supposed to just be the number? Or something else entirely?

Thanks,

Ben

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

Re: [uf-discuss] Microformat to describe a broadcast

[Ben Ward]

On 15 Jan 2007, at 09:41, Michael Smethurst wrote:

I was thinking of something like

[as per hCalendar]

Of course we wouldn't do this without your input; if you disagree  
we'll

stick to hCalendar only


What you're trying to do, it seems, is to categorise the event. The  
accepted way to do this in microformats would be to add the tag  
‘broadcast’.


A parser could then filter events that only have that specific tag.

Tagging specific microformats came up in passing quite recently:
	http://www.mail-archive.com/microformats-discuss@microformats.org/ 
msg05994.html


With some cunning copy, you may already have the word ‘broadcast’ in  
your content already, in which case just hyperlink it to a tagspace  
(http://bbc.co.uk/broadcasts, for example) and add rel=tag.


Regards,

Ben

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

Re: [uf-discuss] Microformat to describe a broadcast

[Ben Ward]

On 15 Jan 2007, at 13:29, Michael Smethurst wrote:


Anyone for hyperlinking to
http://en.wikipedia.org/wiki/Broadcasting
?


That would be absolutely fine. Or any other tag space (Technorati et  
al).


My BBC domain suggestion was based on the thinking that linking  
externally mightn't be appropriate at the Beeb, but if you can  go  
off-site for it then all the better.


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

Re: [uf-discuss] Vote Links: rel="voted-for"

[Ben Ward]

On 18 Jan 2007, at 15:49, Frances Berriman wrote:

Could Sites of the Month not just use rev="vote-for"? As in - this
site voted for me.


Wrong way around Frances, I think.

• rev="vote-for" — ‘this site is a vote for the href’
• rel="vote-for" — ‘href is a vote for this site’

Your concept is correct, though. It definitely seems like a valid  
case for a rel-vote.


So: http://back.to/site/a"; title="Voted ‘site of the month’  
by Site A’ rel="vote-for">Site of the Month! could be used to  
indicate your site had been ‘voted for’ by another.


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

Re: [uf-discuss] Vote Links: rel="voted-for"

[Ben Ward]

On 18 Jan 2007, at 16:50, Ara Pehlivanian wrote:


Yeah except that the spec states that rel "describes the relationship
from the current document to the anchor specified by the href
attribute". So putting "vote-for" in the description would be an
incorrect description. Rather, I think "voted-for" would be a more apt
description to the related link.

Your thoughts?


“The rel and rev attributes play complementary roles -- the rel  
attribute specifies a forward link and the rev attribute specifies a  
reverse link.”

— http://www.w3.org/TR/html401/struct/links.html#rev-link

Starting with rel:

• rel="alternate" means ‘the linked document is an alternate  
representation of this page’


Therefore using rev describes a reverse of that definition:

• rev="alternate" would mean ‘this page is an alternate  
representation for the linked page’


With vote links:

• rev="vote-for" means ‘this page is a vote for the linked page’

and reversed:

• rel="vote-for" means ‘the linked page is a vote for this page’


Hope that clarifies the attributes for you, Ara.

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

Re: [uf-discuss] Vote Links: rel="voted-for"

[Ben Ward]

On 18 Jan 2007, at 21:23, Ara Pehlivanian wrote:

I don't agree that you can simply use rel="vote-for" because it
incorrectly gives the impression that you're "voting for" when really
you were "voted for",


It doesn't give the impression that you're ‘voting for’ though — the  
use of rev or rel attribute determines that.


URL A is a vote for URL B.

That is the statement described by vote links.

Which of those URLs is the current page is determined by choice of  
rel or rev, *not* a grammatical variant of the word ‘vote’.



rel="voted-for"
rel="voted-against"
rel="vote-abstained"


The only difference here is the tense of the word ‘vote’. Moving  
‘vote’ from the present tense to the past tense doesn't change the  
direction of the relationship.


rel="vote-for" would mean ‘The page I am linking to is a vote for  
this page’

rev="vote-for" means ‘This page is a for for the page I am linking to’

Separate terms are really not needed to express what you're asking for.

Ben

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

Re: [uf-discuss] This Week in Microformats

[Ben Ward]

Hi Andy,

On 28 Jan 2007, at 12:27, Andy Mabbett wrote:
The last "This Week in Microformats" was dated 17 December 2006  
(over a

month ago).



Yes it was. I'm somewhat embarrassed by the loss of regularity.


Will there be another? Is some assistance in compiling it needed?


There definitely will be another — I've been wanting to get it done  
for weeks now. I'm just terribly disorganised and increasingly tired  
in the evenings. I think that answers the second question; yes, some  
compilation assistance would be good. Your Wiki page is an excellent  
mechanism.


It's my intention that the next edition of TWIM link to the Wiki  
brainstorm page for people to contribute for the next weeks entries,  
but thank you for bringing it to the attention of the community now.


I consider myself duly prodded, so I'll try and get the roundup  
sorted out over the next few days.


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

Re: [uf-discuss] WikiProject Microformats

[Ben Ward]

On 29 Jan 2007, at 13:45, Costello, Roger L. wrote:

"How" is a microformat added to a wiki page's markup?


The MediaWiki software allows you to directly type in HTML as well as  
using the Wiki shorthand language. It also has a reusable templating  
system, allowing you to enter data into more complex templates in a  
key-value kind of syntax.


However, in most default installs of MediaWiki I've seen, the ABBR  
tag is stripped out. I expect that's just a setting to be enabled.


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

Re: [uf-discuss] Authoritative hCards [was RE: Canonical hCards (was: Search on CSS element)]

[Ben Ward]

On 24 Jan 2007, at 14:51, Ara Pehlivanian wrote:

Just a shot in the dark here, but couldn't the  be
assumed to be pointing to the hCard owner's site where it could be
further assumed that the authoritative hCard would reside? What's
more, if the href in the  contained an id for the
actual hCard in question then you'd be pointing directly to the
correct hCard (in case the page contains multiple ones, for
work/home/etc...)

An example would be: http://mydomain.com/contact.html#myInfo";...>


Whilst the use of fragment URLs is definitely correct as regards  
focusing on specific hCards on a page, you cannot imply authority  
based just on class=url — it's valid and legal that an hCard can have  
multiple URLs, so which would be authoritative?. On my own site, I  
link to my /about page, my Flickr account, Delicious bookmarks and so  
on, all with class="url" and rel="me".


For my money, John Allsopp's idea to reuse rel="bookmark self" [1]  
makes most sense. As well as being gorgeously consistent with other  
existing microformats, it's also a completely graceful addition to  
existing hCards.


The only concern I can see to check is if this would conflict with  
and break the parsing of hAtom/hReview that already use those rel  
values in combination?


It would take the guesswork out of parsing, whilst publishing useful  
information. Additionally, what do people think to situations where  
an hCard contains a A/@REL="bookmark self" but not @class=url? The  
use case being when I don't regard my /about page as being a relevant  
URL for inclusion in my hCard parsing, but do wish to have it  
followed and parsed as the authoritative version.


Ben

[1]: http://microformats.org/discuss/mail/microformats-discuss/2007- 
January/008309.html

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

Vote on this: rel="me self" to indicate an authoritative hCard {was: Re: [uf-discuss] Authoritative hCards [was RE: Canonical hCards (was: Search on CSS element)]}

[Ben Ward]

Chris Messina:


 http://factoryjoe.com/blog/hcard/#hcard"; class="fn
url" rel="me self">Chris Messina
 Citizen Agency
 ...




John Allsopp:
The "definition" of the self attribute value in Atom is "self: the  
feed itself". The term "the" seems to indicate "definitiveness".  
So, I was initially going to argue that "self me" was tautological,  
but in fact, in this sense it is not, and indeed, the addition of  
bookmark is probably tautological.


So, I'd probably +1 this suggestion, […]


+1 from me as well.

Can we gauge wider support for this addition? Any problems from anyone?

Ben

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

Re: Vote on this: rel="me self" to indicate an authoritative hCard {was: Re: [uf-discuss] Authoritative hCards [was RE: Canonical hCards (was: Search on CSS element)]}

[Ben Ward]

On 31 Jan 2007, at 12:08, Colin Barrett wrote:
Can I get a clearer idea of what exactly is people are +1-ing? I +1  
@rel="self me", but am not willing to give my vote yet on using  
, as it's not entirely clear if we're talking about  
mandating it, recommending it, etc. FWIW I'm not entirely convinced  
it's necessary to have it.


Apologies, I perhaps should have created a fresh example rather than  
re-use Chris' original effort.


We are voting only on the use of @rel="me self" to reference an  
authoritative hCard that parsers should follow.


e.g.


  http://ben-ward.co.uk/about"; rel="me  
self">Ben Ward


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

[uf-discuss] Authenticity of Authoritative hCard (was: Re: Vote on this: rel="me self" to indicate an authoritative hCard)

[Ben Ward]

On 31 Jan 2007, at 14:49, Ara Pehlivanian wrote:

Just to stir the pot a little, and maybe it's a good idea to consider
authenticity in the whole discussion of authoritative cards. What
guarantees that when someone creates an hCard and puts rel="me self"
that they are giving the correct URL and that it isn't someone
impersonating you?


The authoritative version of the hCard is only going to be relative  
to the published hCard itself. The situation doesn't change. Someone  
could already write an inaccurate hCard for me on their website. They  
could write a more thorough version and link from one to the other  
with rel="me self".  This addition doesn't affect the authenticity.


Authenticity falls out of scope of hCard alone. Layer in some OpenID  
and you can have start to imply some authenticity. (e.g. Parse an  
hCard at the OpenID url and follow rel="me self" to another domain.)


If you mean, someone at ‘BenWardSmellsAwful.com’ (don't register  
that, please) writing an hCard and linking to ben-ward.co.uk/about  
with rel="self me", the relationship is such that the Fake Ben's  
hcard is discarded in favour of my real one. This does not allow  
someone to describe ‘this hCard here is the authoritative version of  
that one over there’. The direction of parsing disallows fakes.


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

Re: [uf-discuss] Authenticity of Authoritative hCard (was: Re: Vote on this: rel="me self" to indicate an authoritative hCard)

[Ben Ward]

On 31 Jan 2007, at 15:50, Ara Pehlivanian wrote:

Yes, but what if someone registers ben-ward.net and puts up a fake
card on that site. Then he goes and publishes a partial hCard on
myspace and points to ben-ward.net/about with rel="self me". He's
effectively hijacked your identity and/or caused confusion and there's
no real way to verify who's who or who's telling the truth.


That's still no different to life without rel="me self".

I happen to own the domains  and . Note  
hyphens. I do not own  ,   nor any other  
variant.


Domains do not prove identity. What I can do is make my entire  
‘online identy’ parsable by linking between my domains and my social  
network profiles using rel="me". That doesn't tell you anything more  
about me as a person than the fact that , ward.co.uk> and  are part of the same  
personal network of sites.


The owner of Ben-Ward.net could have his own personal network of  
sites too, but they would not be linked to from my own authoritative  
hCard at ben-ward.co.uk/about. Nothing stops him add rel="me" to his  
hcard pointing to my site, but that takes us well out of scope of  
hcard, and is still a different issue — not something introduced by  
@rel="me self"


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

Re: Vote on this: rel="me self" to indicate an authoritative hCard {was: Re: [uf-discuss] Authoritative hCards [was RE: Canonical hCards (was: Search on CSS element)]}

[Ben Ward]

On 31 Jan 2007, at 16:15, Ryan Cannon wrote:

It's definition is "A link to yourself at a
different URL"[1].


Correct. Which is still valid in the rel="me self" case.


According to the spec, rel="self me" is invalid *unless*
you do not include the XFN profile on your Web site.


Sorry, I've got muddled here. According to which spec? Are you  
referring to the “Exclusive of all other XFN values” part of the  
@rel=me spec [1]? That's also maintained, as @rel=self is not part of  
XFN, but (propositionally) of hcard.


[1]  http://www.gmpg.org/xfn/11#me

Ben

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

Re: [uf-discuss] Authenticity of Authoritative hCard (was: Re: Vote on this: rel="me self" to indicate an authoritative hCard)

[Ben Ward]

On 31 Jan 2007, at 17:03, Ben Ward wrote:
The owner of Ben-Ward.net could have his own personal network of  
sites too, but they would not be linked to from my own  
authoritative hCard at ben-ward.co.uk/about. Nothing stops him add  
rel="me" to his hcard pointing to my site, but that takes us well  
out of scope of hcard, and is still a different issue — not  
something introduced by @rel="me self"


Actually I'm wrong here. The XFN spec points out that @rel=me must be  
symmetric, so the owner of ben-ward.net could *not* validly link to  
ben-ward.co.uk with @rel=me unless I linked back likewise.


“me: A link to yourself at a different URL. Exclusive of all other  
XFN values. *Required symmetric*.”


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

Re: Vote on this: rel="me self" to indicate an authoritative hCard {was: Re: [uf-discuss] Authoritative hCards [was RE: Canonical hCards (was: Search on CSS element)]}

[Ben Ward]

On 31 Jan 2007, at 17:24, Ara Pehlivanian wrote:

Ben,

Don't you think he has a point though? If you think of it, rel="me"
could suffice in that it refers to yourself at another URL (in line
with the idea of an authoritative hCard) and once you get there and
read that hCard and discover that it doesn't contain a rel="me", you
know you're at the authoritative card. In that sense, why add "self"?
Or am I now missing something?


The authoratitive hcard will also contain @rel="me". Firstly, to  
fulfil XFN it must link back to the linking resource and as a full  
hCard it will still contain URLs with @rel="me" pointing to the other  
sites I own.


@rel=me indicates that the URL on the end of it belongs to the same  
person
@rel=self is adopted from the definition of self in Atom. Quoting  
John Allsopp: The "definition" of the self attribute value in Atom is  
"self: the feed itself".


My understanding therefore, is that @rel=me indicates that it is the  
same person. @rel=self indicates that it is the same hcard. Therefore  
the absolute authoritative hcard we speak of may (I expect will)  
contain other links with @rel=me but will not contain a link with  
@rel=self.


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

Re: [uf-discuss] Microformats, WebApps 1.0 and UI widgets in browsers

[Ben Ward]

Hi Karl

On 1 Feb 2007, at 15:09, Karl Dubost wrote:
hCalendar: "description", "summary", "category", "location",  
"status", "last-modified"

hCard: "adr", "street-address", "email", "geo", etc.
and plenty others.

You seem to have missed the bit where I was saying that any  
mechanisms for switching being a specific class surrounding class  
names, a profile URI attribute, etc would be fine.




I'm not sure I see the problem here. Those class names are indeed  
generic and used all over the web, but they should only trigger user  
interface enhancements when they are children of ‘vcard’, ‘vevent’,  
‘hatom’, ‘hatom’ elements.


UI would surely only respond to valid and complete microformats on a  
page, not the sub-parts of them.


In my pages for example, I have started to change my instances of  
title for titre, and author to auteur, because I do not want to  
have to trigger something I didn't want.


Again, unless I've missed something in the above, that isn't  
necessary as those title and author class names are children of an  
appropriate microformat parent element, so would be ignored by a  
microformats parser.


Please could you elaborate if I've misunderstood the implications of  
your concern.


Kind regards,

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

Re: [uf-discuss] mime types and microformats

[Ben Ward]

On 1 Feb 2007, at 15:37, Rob O'Rourke wrote:
If (x)HTML documents when served as text/html are treated as HTML  
how are the microformats still working? Does this mean microformats  
will work under an HTML 4.01 doctype?


Microformats are generally parsed absolutely fine in both XHTML and  
HTML, for one of two reasons:


• Some parsers (such as JavaScript bookmarklets) parse the HTMLDOM  
with script, after the browser has done its parsing so at that level,  
it makes no difference whether the document is HTML or XHTML.
• Other parsers (such as X2V) use an XSLT stylesheet to convert from  
XHTML into vcard or icalendar. These first run pages through a tool  
called Tidy, which converts HTML to well formed XHTML to allow the  
XSLT to run.


Basically, microformats are easier to parse directly if you use mark- 
up that validates as XML (the mime type doesn't make a difference in  
practice), but since open source tools exist that makes switching  
HTML into XHTML simple, real world parsing is very tolerant.


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

Re: [uf-discuss] hMood/hPresence?

[Ben Ward]

Hi Sam,

On 31 Jan 2007, at 17:26, Sam Sethi wrote:
Just wondering does presence and mood really apply to a  
microformat?  What I

want is federated presence across applications and devices.


Personally I hope XMPP becomes the interoperable standard for  
presence and

then we an build apps on top of this?


I've not got a particular interest in a mood/presence microformat  
personally, but I think it's worth pointing out that you've got two  
different issues in hand there. I completely agree that having some  
means of unifying ‘presence status’ across applications would be  
fantastic. I also agree that a microformat is not an obvious answer  
to solve that problem (although it could be done and could work, all  
the same).


The focus of an hMood microformat would be different though,  
reflecting the fact that right now, people can and do publish their  
moods and presence in HTML. Separately from IM and all the rest, but  
published all the same. On the premise that something useful can be  
done with this information that is already being published, a  
microformat would just make that information discoverable in a  
consistant manner. Nothing more.


Now as you think ahead, of course if *could* be used by services one  
source of unified status, but that's not the problem a microformat  
would be focused on solving.


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

Re: Vote on this: rel="me self" to indicate an authoritative hCard {was: Re: [uf-discuss] Authoritative hCards [was RE: Canonical hCards (was: Search on CSS element)]}

[Ben Ward]

On 8 Feb 2007, at 19:02, David Janes wrote:

On 2/8/07, Ryan King <[EMAIL PROTECTED]> wrote:

Nothing special is needed at /blog/contact/.

-ryan


But that's the authoritative hCard. […]





Sorry if this sounds pedantic, I'm not trying to be. There's some
assumption in what you're saying that I'm not getting.


The difference in interpretation is this: You're looking to describe  
the *one true hcard*, to rule them all, bind them in the darkness and  
so on and so forth.


What Ryan is describing is *relative*. So linking with UID from one  
small hcard in the footer of ben-ward.co.uk to a larger, more  
complete hcard at ben-ward.co.uk/about is saying, very simply: ‘/ 
about is the authoritative hcard _of this hcard_’.


Now, to step back into this discussion after a little break, this use  
of UID solves *my* problem; a way to point from small snippet hCards  
that contain name/URL to larger ones which contain comprehensive  
contact details. I'm not trying to rule Middle Earth, just to say  
‘there's a more comprehensive hcard over here’. And for me, this  
would do the trick very nicely.


Of course, there's nothing to stop me linking _that_ ‘/about’ hCard  
to another one somewhere else; such practice should not be  
disallowed. But at this point, that could be getting out of 80:20.


Regards,

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

Re: [uf-discuss] adr should be

[Ben Ward]

On 25 Feb 2007, at 23:19, Thom Shannon wrote:

Brian Suda made a point at barcamp about the documentation using  
only divs and spans, so people don't get confused and think that  
the element types matter. Obviously people should use the most  
suitable elements in the context they're using them. But I think  
this should be made much clearer in the wiki.


Actually it was me who made that point, unless Brian did as well,  
separately from the panel. Anyway…


Some time ago I suggested we put a disclaimer at the top of each spec  
making it clear that SPAN/DIV are used for example purposes and then  
have a new set of ‘rich examples’, complementing the existing ones,  
showing more diverse mark-up in use with microformats.


Unfortunately I suck and haven't had the organisation to do anything  
with it, Though it remains on my to-do list.


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

[uf-discuss] [hListing][hReview] 'Description' conflict

[Ben Ward]

I was recently trying to implement mark-up with both hListing (draft) 
and hReview combined. For the most part the properties align except in 
the case of 'DESCRIPTION'.


hListing: According to the schema, description is REQUIRED, makes no 
assertion about detail or completeness of content marked up with 
description.
hReview: “This optional field contains the full text representing the 
written opinion of the reviewer”


The conflict here is that review specifies 'full text' whilst hListing 
is permitting it to be used more loosely. But, if a piece of content is 
marked up with both hListing AND hReview, even though the description is 
optional in hReview, an hReview parser will not find 'full text' from 
the description classname.


Since 'SUMMARY' is already claimed in hListing for the purposes of the 
listing title, I'd like to solicit suggestions on resolving the conflict.


Thanks,

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

[uf-discuss] Regarding POSH and misuse of the microformats logo

[Ben Ward]

Hi all,

I've obviously been following the recent push to have POSH adopted as  
a buzzword to discourage people from mis-using the term ‘microformat’  
in their semantic endeavours.


Now the whole point of this is to differentiate semantic HTML from  
microformats, discourage the further ambiguation of the terms. So to  
be honest I'm a bit put out by the badges that have been added to  
http://microformats.org/wiki/posh#POSH_Bling_for_your_Blog which  
include the microformats logo.


As part of our ‘community mark’ experiment I'd like to object to that  
usage of the microformats logo and ask those badges be removed.  
Regardless of what anyone thinks of the term, POSH is explicitly  
supposed to be a super-set of microformats, a generic term invented  
to help protect the microformats name from being generalised. If the  
first thing people do — on our own wiki, no less — is tack the  
microformats logo to it then it will do absolutely nothing toward  
that goal, and with all the current hype will only accelerate the  
loss of ‘microformat’ as a name for the Process.


POSH is not a microformat. The documented presence on our wiki is  
acceptable as ‘microformat’ mis-use is a common problem for us, but I  
object to it being presented as part of ‘microformats’ through  
association with the logo. It's just going to cause more confusion.


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

Re: [uf-discuss] Regarding POSH and misuse of the microformats logo

[Ben Ward]

Right,

I've set up a vote for this on the Wiki. As explained in my Wiki  
commit comment, with the POSH page being something of a reference  
rather than a page of active microformat development, I judge it to  
be inappropriate to tack the vote on to the article itself and have  
created a Talk: page for the vote instead.


If interested parties could please contribute and offer any  
objections by Wednesday evening (allowing the UK bank holiday weekend  
and two working days for collection).


http://microformats.org/wiki/Talk:posh

Cheers,

Ben

On 3 May 2007, at 13:06, Serdar Kiliç wrote:
I agree, there shouldn't be an association with the Microformats  
logo with that of any POSH logo. As you say, it's important to be  
able to distinguish the two, which I believe is accomplished with  
the information found on the wiki page.



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

Re: [uf-discuss] Yahoo introduces no-search microformat like function

[Ben Ward]

On 4 May 2007, at 22:19, Ted Drake wrote:


What’s the traction for something like this and “no-follow” to get
integrated into the microformat platform?


Well, robots-nocontent is not part of the the robots-exclusion draft,  
which in itself has not been updated for over 18 months.


I contacted Priyank yesterday and he confirmed that Search have not  
implemented any of the robots-exclusion draft itself, nor have they  
implemented an opposite ‘robots-content’ class.


I will email him again to see if we can get a concise specification  
of the indexing behaviour for robots-nocontent page sections so that  
it can at least be documented. If Peter Janes is still active here or  
if anyone else has an interest in picking up the robots-exclusion  
spec then it will be up to them and their work within the process to  
determine if the implementation can be documented as part of it.


It seems like as good a time to ask; does anyone in the community  
still have an active interest in Robots-Exclusion? Are there any  
implementations?


(Since I know disclosure is appreciated: If it's not already clear  
from the communications documented in this message, I recently  
started working for Yahoo! Europe. With relevance to this issue  
though, I am not in any way involved in Yahoo! Search. In a more  
general sense, at this time, none of my contributions to this list  
are representative of Yahoo! and so on and so forth yada yada)


Regards,

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

Re: [uf-discuss] uF Tools for Internet Explorer?

[Ben Ward]

On 9 May 2007, at 00:22, Charles Iliya Krempeaux wrote:

The rumor is that IE8 will have native support for Microformats.


Please correct me if I'm wrong, but I'm not sure those rumours have  
ever been supported by anything out of Microsoft. There's a lot of  
circumstantial reasoning (Microsoft's efforts with Live Clipboard,  
Vista shipping with an iCalendar based calendar application and  
updated Contacts app), but I don't know that any IE developer has  
substantiated the link even slightly.


In fact, last I recall reading for IE.next on the IE blog was a focus  
on JavaScript and DOM scripting enhancements.


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

Re: [uf-discuss] microformats for normal people, like my mum

[Ben Ward]

On 27 Jun 2007, at 23:09, Thom Shannon wrote:
I know this topic comes up a lot and we'd all like to see  
Microformats change the lives of millions of ordinary internet  
users, that's why we're all here!


My friend just asked me an interesting question, is Microformats  
the right name for it?


Sorry, but this discussion seems absurd to me.

Microformats is a good name for developers. It encompasses a large  
range of different, mostly discrete and often unrelated data formats.  
It has nothing at all to do with user-facing exposure of that data.


No-one is ever (read: should ever) create a web browser with a ‘Get  
Microformats’ button other than as a developer testing tool. But the  
idea that we need some other name with ‘Super’, ‘Hyper’ and ‘Smart’  
in the name is verging on the hilarious.


Here's what should happen:

Developers will use a microformat in their page to describe reviews,  
addresses or calendar appointments. User agents will then expose them  
as… reviews, addresses and calendar appointments.


I cannot for the life of me see why we are trying to abstract useful  
functionality at a user-end with a nonsensical name like ‘Smart Data’  
when ‘Address’, ‘Event’ and ‘Location’ have served the English  
language very well so far.


Finally, an all-encompassing term for all microformats going to be  
useless to end users. Apart from the aforementioned abstraction of  
what the data really is and really should be used for, microformats  
are so varied that a generic term will be meaningless. XOXO and Geo?  
Branding them ‘Hyper Smart Data Enabled’ isn't going to help an end  
user any more than ‘microformat’. Exposing functionality where useful  
is. And that functionality doesn't need a µf.org endorsed name; the  
functionality should be named as appropriate, not the data format.


To draw a parallel: We do not ‘consume HTML documents’, we ‘read web  
pages’. Consumers of microformats will not ‘consume Smart Data’ they  
will ‘add contacts to their address books’, ‘print address labels’,  
‘find other employees of this organisation’ and ‘show a map of this  
location’. I would strongly discourage any implementer from trying to  
dress up simple functionality with a catch-all term. It will be  
utterly confusing users with yet another hunk of IT jargon.


Thanks,

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

Re: [uf-discuss] hRelease

[Ben Ward]

On 27 Jun 2007, at 23:40, Guillaume Lebleu wrote:
If we they choose not to follow the microformat process, what about  
suggesting them to call their specification a hFormat instead of a  
microformat?


‘format’ — sans ‘h’ — and ‘semantic HTML’ are serving well enough I  
think, without throwing another piece of (dangerously close to  
microformat spec terms) terminology to the mix.


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

Re: [uf-discuss] Date of Death in hCard

[Ben Ward]

On 27 Jun 2007, at 20:33, Andy Mabbett wrote:
There having been no comments, much less objections, I intend to  
proceed with this, using "died" as the property name, in five days  
from the time of posting.


I have no objections to this. It's a useful extension to hCard as a  
‘profile’ format; which it is very much being used for on the web.


I would be prepared to have ‘hCard profile extensions’ separated from  
hCard, though. There's value in the hCard spec being 1:1 with vcard,  
especially with regards compatibility with desktop tools.


Although this particular extension wouldn't have a major impact on  
that use, if we're to open the can of adding new fields, I'd like it  
considered that we clearly separate it, perhaps into a separate   
specification, citing hCard as the base and then fully specifying  
additional fields.


That way it remains valid to implement hCard for the purposes of just  
representing vCard on the web, and more suitable implementations  
could embrace these extensions as well.


Does anyone agree?

Ben

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

Re: [uf-discuss] Re: Generating valid unique IDs for hAtom

[Ben Ward]

On 22 Jun 2007, at 07:07, Toby A Inkster wrote:

What's wrong with using Permalinks as an id?

If you need to make several entries onto the hAtom feed referencing  
the
same URL, then you can just add "#ref-20070722", "#ref-20070723"  
and so on

to the end of the URL to make it unique.


The best starting point about identifiers for Atom was written by  
Mark Pilgrim:


• http://diveintomark.org/archives/2004/05/28/howto-atom-id

It includes instructions on generating Tag URIs and also explains why  
permalinks are sub-optimal as IDs.


Ben

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

Re: [uf-discuss] microformats for normal people, like my mum

[Ben Ward]

On 28 Jun 2007, at 14:40, Thom Shannon wrote:
I get your point, but as Alex pointed out people are interested in  
this microformats thing but dont want to call it that, journos are  
refusing to talk about it because "the term 'microformats' would  
only appeal to developers, and not the average reader"


But it is impossible to have a meaningful or descriptive name that  
catches all microformats, let alone to an ‘average reader’. I'm also  
not sure which subset of journalists wish to write articles about the  
data formats themselves, but whose audience would balk at a reference  
to microformats.org.


Anyone writing for the average user would surely be writing in the  
context of browser functionality (as and when it ships: namely  
Firefox 3). And when referencing the functionality of those features,  
it makes most sense to use the terms ‘address’, ‘location’, ‘map’,  
‘event’, ‘appointment’, ‘contact’ or ‘business card’ and other such  
words. That's all microformats are to end users. We provide a  
standardised, digital form of those physical-world concepts. A  
journalist could write ‘Firefox 3 allows you to interact with  
business cards and events in web pages like never before, bridging  
the gap between the pages you read and other applications’. That is  
surely a gazillion times better than trying to encourage ‘Firefox 3  
ships with support for Hyper Data, which allows web pages to…’.  Such  
a generic and meaningless term not only adds nothing, but distracts  
from the real benefits of Microformat deployment (by which I mean all  
the name suggestions in this thread, not just my facetious overuse of  
the word ‘hyper’).


We need a way to get across to people that content can be lifted  
out of pages and used in useful ways, when those pages support it.  
And people need to call it something. Maybe it should just be  
"Reusable Information".


For the people who will be putting the data in the pages — developers  
— we have names. Yes, microformats and h* is all very techie, but  
that's perfectly acceptable for developers.


End-users don't need to know anything at all about _how_ or _why_  
their new browser functionality works, only that it's an awesome new  
feature that's going to improve their life.


Who is the group in the middle that this wooly new terminology is  
going to serve? I don't see it.


Ben



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

Re: [uf-discuss] microformats for normal people, like my mum

[Ben Ward]

On 28 Jun 2007, at 15:59, Thom Shannon wrote:
yes, it's a "thing", it's different. FF3 can't just add any address  
you see to your address book, its a specific kind of address that  
just looks the same, and you need a browser or plugin or something  
that understands that specific "thing"


So whats the thing called, micro-what? or "Resuable Data" (with the  
MF icon!)


I'm still not sure there's anything there that can't be served with  
the term ‘rich web page’ or ‘semantic web page’ — two terms already  
in use. What is the semantic way to mark up a business card? hCard.


If some reference to the page specifics is required in documentation  
somehow, does ‘microformatted content’ or ‘microformatted web page’  
not suffice?


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

Re: [uf-discuss] hCard to vCard via JavaScript

[Ben Ward]

On 25 Jun 2007, at 18:55, Rickards, Julian (NDM) wrote:

Although the two Web-based solutions are great, for anyone behind a
firewall, it might not work so a local JS solution may be the way  
to go.


http://leftlogic.com/lounge/articles/microformats_bookmarklet

As far as I remember, this bookmarklet uses pure JavaScript for the  
conversion between h and v, and then generates the output vcard or  
icalendar download as a data:// URI. The limitation is that Microsoft  
IE does not support data URIs, but Webkit, Mozilla and Opera do.  
Potentially you could write script that would do it in-page where  
available and otherwise fall back to a Technorati URL.


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

Re: [uf-discuss] Date of Death in hCard

[Ben Ward]

On 28 Jun 2007, at 15:37, Andy Mabbett wrote:
We'd then have two standards, on being a subset of the other, and  
the distinguishing feature would be that the subset is defined by  
an obscure standard that most people have never heard of.


‘Heard of’ perhaps not, but it is very, very widely used.


That doesn't seem to fit with the microformats ethos, at all.


On spitting the spec completely I agree; it isn't really friendly to  
anyone wishing to work with both specs. But I think that ‘extensions’  
should be very clearly labelled such that it is abundantly clear when  
vcard is diverged from. Either through ly emphasised wording  
prefixing each extension (if integrated into the sections also  
containing vcard properties), or placed on a separate extensions page.


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

Re: [uf-discuss] Re: Generating valid unique IDs for hAtom

[Ben Ward]

On 16 Jul 2007, at 11:08, Toby A Inkster wrote:

As for #2, it's
fixing the wrong problem: if changing permalinks causes the Atom ID to
change, then you should fix your permalinks which are not supposed to
change!


Of course _perma_links are not supposed to change. But I think the  
point that Mark Pilgrim makes, and one that I agree with, is that  
principal does and will collapse in real-world tools.


Migrating between CMS systems, rebranding to a new domain name,  
switching advocacy to support the ‘no-WWW’ movement? All perfectly  
likely and reasonable things to do, which CMS's generating permalinks  
have not been designed to support and a problem which, regardless of  
the ideal, many (most?) authors simply won't account for.


There may not be a solution to this. Fitting a tag URI into page  
content seems clumsy for sure, and those same CMS systems that make  
permalinks less-than permanent are publishing dynamically generataed  
permalink URLs as IDs all the while. I'm not sure that we're in a  
position to ‘fix’ the problem. But I think we should try to exhaust  
the non URL options thoroughly.


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

Re: [uf-discuss] Invalid "adr" on Flickr

[Ben Ward]

On 29 Jul 2007, at 01:24, Ben O'Neill wrote:
(Note: That code wasn't in the webpage when I went to it but that's  
irrelevant)


It only appears on _your own, non-geotagged_ photos. When you view  
someone else's, it's not there.


I've filed a bug with the Flickr team so it will hopefully get tidied  
up sometime in the future.


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

Re: [uf-discuss] Geo precision

[Ben Ward]

On 27 Aug 2007, at 01:19, Michael MD wrote:
I remember some discussion a while back about "fuzzy" locations ..  
but I

can't remember if anything was worked out.


No, nothing got worked out of that one.

Since then the only additional information I've found is that Flickr  
stores accuracy (as an integer) based on the zoom level of the map  
when you place a photo. In fact, if you zoom all the way out and  
place a photo you'll get a notice warning you that the location is  
too approximate and the photograph won't show up at higher zoom levels.


I'll see if I can find out what the range of accuracy numbers is, and  
what scale they correspond to.


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

Re: [uf-discuss] hCard multiple locations

[Ben Ward]

On 27 Aug 2007, at 14:54, Jason Karns wrote:

Although not relevant to the discussion, I believe I will continue to
mark up each physical address with its own GEO and let the parsers
extract what they will.  Unless, of course, a more appealing solution
or convincing argument is proposed.


This is possibly an application of the VCARD AGENT property?

http://www.ietf.org/rfc/rfc2426.txt (§3.5.4 AGENT Type Definition),  
and the VCARD-RDF implementation at: http://www.w3.org/TR/vcard-rdf  
(§3.6 Agent property).


This describes vcards within vcards, such as for employees of an  
organisation. However, it has never been put into practice in hCard,  
usually dismissed because popular desktop address book applications  
apparently do not handle AGENT.


It sounds reasonable that multiple entities for a business would be  
agents.


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

Re: [uf-discuss] Re: Need for plain-language intros for each microformat

[Ben Ward]

On 5 Sep 2007, at 20:18, Toby A Inkster wrote:
Syntactically the URI would still work, however, semantically it  
would have
been broken, that is, it is bad to not only change URIs so that  
they 404 and
just plain don't work, but it is also bad to change the *meaning*  
of that

URI.


As long as there is a clear link to the specification from the
explanation, then I disagree that it's really changed the meaning
of the link target.


Whilst the ‘meaning’ in terms of microformats.org/wiki/hcard being a  
page about hCard would still be valid, the context in which that URL  
is used by publishers on the internet. Tutorials may link to the  
entire page accompanied by the text ‘read the hCard specification’,  
whilst other pieces could be linking to fragment identifiers within  
the page to reference a specific part of the spec.


As such, I also oppose that the specifications be moved from the  
current root locations. Potentially we could agree that future  
specifications include ‘-spec’ in the URL, but current URLs and  
content IDs need to remain the same.


I would move that plain text ‘-info’ pieces be written for each spec  
and an introductory paragraph from each be placed at the top of each  
spec to more accessibly introduce the document, with a link to the  
‘All about hCard’ page.


Regards,

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

Re: [uf-discuss] Correct way to use the "key" property of hCard

[Ben Ward]

I don't know the answer to this particular problem, but:

On 17 Sep 2007, at 22:23, Scott Reynen wrote:

public key


‘PGP’ is not an abbreviation of ‘public key’.

Assuming the rest of the example is correct, you'd need to do  
something like:



  PGP Public Key:
  Blah


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

[uf-discuss] [hListing] Listing

[Ben Ward]

Hi,

On the subject of reviving µf development, I've been doing a lot of  
implementation work with the hListing draft and over the next few  
weeks will be hoping to document what we've been able to do with it.


In the follow up to that I'd like to see about moving the draft  
along, tightening it up and taking a view toward making a release of  
it. That work will be sent to the microformats-new mailing list as it  
happens.


I know there are some other implementations of hListing already in  
the wild: EdgeIO, Dealtagger and Emurse acording to the Wiki. Is  
there anyone from those companies still active here who wants to be  
involved?


So please consider this a heads up for making new progress on Listing  
and if anyone at all is interested, please take a look through the  
existing work (http://microformats.org/wiki/listing) and post and  
thoughts to Microformats-New.


Thanks,

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

Re: [uf-discuss] hreview using include pattern

[Ben Ward]

On 9 Oct 2007, at 00:57, Brian Miller wrote:

In looking at the hreview examples (apple, readandtravel) who have a
similar structure, they usually repeat the item information in each
review and use css to hide it.  This seems messy from a semantic and
accessibility point of view.  Most screenreader users would not enjoy
hearing the item information every time.


I haven't checked, but they may be slightly older implementations.  
For a time there was a problem with the OBJECT include pattern in  
Safari, which led to the Anchor based include pattern being designed.  
That in turn is sub-optimal as empty-anchors are poor accessibility.  
So, if those implementations were built before Safari fixed its  
OBJECT bug — or before that fix was regarded as wide-spread — then  
they may have compromised with repeating data.


The new hReview deployment we've just put out uses the OBJECT pattern.

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

[uf-discuss] OBJECT include pattern and excess HTTP requests

[Ben Ward]

Hey hey,

Quick question for people publishing hReview.

Long ago when the OBJECT-include pattern was first raised, there was  
a bug in Safari that made it unworkable. That bug got fixed.


However, there appears to be a separate, very serious browser issue  
whereby browsers are making additional HTTP requests for each OBJECT  
include in a page, even though the data attribute is making a same- 
page fragment reference (#review-item or whatever).


I've swapped for the hyperlink include pattern (however, repeating  
the review item name as the InnerText of the anchor, so as not to  
create poorly accessible empty anchors).


What I want to know is if anyone else knows of a robust solution to  
prevent browsers firing off these extra requests from the presences  
of OBJECT?


My feeling is that the Wiki content on the include pattern needs a  
tidy anyway, but if this issue with firing unwanted requests is  
unfixable, I think we should restructure to promote the hyperlink- 
include as the first-choice solution.


I should emphasise that whilst it may be a non-issue or trivial for  
small-scale publishing, firing off these extra requests is a deal- 
breaker performance problem on the scale of sites we have at Yahoo.


Ben


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

[uf-discuss] General Definition List Pattern

[Ben Ward]

Idea that's been brewing in my mind for a little while of using the  
semantics of a definition list better in microformats.


Take the following example from an hCard:


  Home
  01223 123 456
  Fax
  01223 123 457
  Cell
  07734 703 618


You would still declare explicit class names on the DT and DD  
elements — no implicit classes should be applied based on it being a  
DT/DD — but the rule works as follows:


In a DL with class "foo" , each set of DT+DD is treated as a separate  
parent "foo". So in the above example, the DL has class "tel", but it  
is parsed as if you have three standalone "tel" elements for each  
actual telephone number.


We have something along these lines in our mark-up at the moment, so  
I'd obviously quite like to see if it's feasible for parsers to  
handle this.


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

Re: [uf-discuss] hreview using include pattern

[Ben Ward]

On 9 Oct 2007, at 18:39, Brian Miller wrote:

Great, so I can use the object.  So back to the original question: Can
the item information be separate from the first review and just  
included

in the first review using object?  If yes, then does that item
information need to be wrapped in hreview?



Yes it can. Our reviews have the ‘item’ part at the top of the page  
and then the reviews themselves appear further down.



Any tools to test and validate?


Operator for Firefox has a debug mode that shows the parsed object  
structure from the page, so you can see that everything is as you  
expect.


One HUGE update to what I've said previously though. I'll quote my  
other mail to the list from earlier today. In short, we've had a  
problem with using OBJECT, so switched to the alternative hyperlink  
include pattern instead (http://microformats.org/wiki/include- 
pattern#hyperlink_include_example)


[…] there appears to be a separate, very serious browser issue  
whereby browsers are making additional HTTP requests for each  
OBJECT include in a page, even though the data attribute is making  
a same-page fragment reference (#review-item or whatever).


I've swapped for the hyperlink include pattern (repeating the  
review item name as the InnerText of the anchor, so as not to  
create poorly accessible empty anchors).


Please do note the last point about including inner text in the  
hyperlink. The wiki is out of data and shows examples with empty A  
elements. That's bad accessibility practice, and I intend to rectify  
the examples once I get some consensus from my ‘OBJECT include  
pattern…’ thread.


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

[uf-discuss] Cross-Page Includes (was: OBJECT include pattern and excess HTTP requests)

[Ben Ward]

In the interests of tidy administration, I'm splitting this thread.  
The originally raised and the proposal for including remote content  
within microformats are very different issues and it's important that  
the original thread stay on track.


Thanks.

On 10 Oct 2007, at 02:59, Michael MD wrote:

PS It's then just a small step to allow off-page includes, which is
related to the interlinked hCards on different sites that I was
talking about recently on this list.  If anyone can come up with more
real-world use-cases for this type of cross-site uF linkage, I'd be
most grateful.  Looking further ahead (wrong list for that, I know)
I'd see good mashup opportunities from allowing more uF
interlinkage...=0)


interesting ... but the extra complexity that would add to parsers  
(requiring them to do the extra requests) would be a problem.. also  
what about pages being looked at offline?

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

Re: [uf-discuss] How to handle empty lists ?

[Ben Ward]

On 30 Oct 2007, at 17:09, [EMAIL PROTECTED] wrote:



I'm new to microformats.


Welcome!


I'm trying to use microformat style xhtml to represent some data.


OK. Howeber, what you're using is really semantic HTML, it's  
precisely what the class attribute was designed for. Call it a  
pattern or a data format as you like, but keep in mind that  
‘microformats’ are a process by which formats are defined, not a  
syntax in itself. The syntax you're using is just HTML.


Somme data are lists of items represented by an  element. XHTML  
(HTML) do

not allow empty lists, but my data model uses empty lists.

How to deal with this :
- use an empty  element,
- use a fake element ,
- use empty list and ignore xhtml rule,
- ... ?



To be pedantic, is an empty list really a list if it doesn't list  
anything? For whatever pattern you are designing, why not just define  
a parsing rule based on the absence of the list? If the list is  
present, then you know that there is data, if it is absent then you  
know there is not. Regardless of validation, including an empty list  
in an HTML document is poor code really.


Ben



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