From rff.rff at gmail.com  Sat Apr 19 04:53:57 2008
From: rff.rff at gmail.com (gabriele renzi)
Date: Sat Apr 19 04:54:01 2008
Subject: [uf-new] hListing photo field
Message-ID: <828083e70804190453v35bb9753gb523c413c70ac43f@mail.gmail.com>

looking at the kelkoo output, I see

<li class="result hlisting cat-123 prod-1234 offer
offer-manufacturer_products first" id="..">
    <div class="information-container">
     <ul class="information">
      <li class="photo">
        <a href="..">
        <img alt="" src="..."/>
        </a>
      </li>
...

Am I right in assuming that "photo" is an optional field of the
Listing, which was formerly described as being a sub-filed of listing
> item ?
Furhermore, am I right in assuming that the parsing rule would be
  get @src from  a IMG tag under .photo  ?

Thanks to everyone in advance.

-- 

blog it: http://riffraff.blogsome.com
blog en: http://www.riffraff.info
From csarven at gmail.com  Sat Apr 19 07:27:31 2008
From: csarven at gmail.com (Sarven Capadisli)
Date: Sat Apr 19 07:27:33 2008
Subject: [uf-new] hListing photo field
In-Reply-To: <828083e70804190453v35bb9753gb523c413c70ac43f@mail.gmail.com>
References: <828083e70804190453v35bb9753gb523c413c70ac43f@mail.gmail.com>
Message-ID: <d4154bcf0804190727n38015bb2w825bd9f56336646f@mail.gmail.com>

On Sat, Apr 19, 2008 at 7:53 AM, gabriele renzi <rff.rff@gmail.com> wrote:
> looking at the kelkoo output, I see
>
>  <li class="result hlisting cat-123 prod-1234 offer
>  offer-manufacturer_products first" id="..">
>     <div class="information-container">
>      <ul class="information">
>       <li class="photo">
>         <a href="..">
>         <img alt="" src="..."/>
>         </a>
>       </li>
>  ...
>
>  Am I right in assuming that "photo" is an optional field of the
>  Listing, which was formerly described as being a sub-filed of listing
>  > item ?
>  Furhermore, am I right in assuming that the parsing rule would be
>   get @src from  a IMG tag under .photo  ?

Sounds right. However,

I propose instead of using class PHOTO in ITEM, we reuse the figure
format [1] in hListing.
e.g.,

<div class="item">
  ...
  <div class="figure">
    <img class="image" alt="foo">
  </div>
  ...
</div>


[1] http://microformats.org/wiki/figure

Sarven Capadisli
http://www.csarven.ca
From lists at ben-ward.co.uk  Sat Apr 19 08:06:11 2008
From: lists at ben-ward.co.uk (Ben Ward)
Date: Sat Apr 19 08:06:32 2008
Subject: [uf-new] hListing photo field
In-Reply-To: <828083e70804190453v35bb9753gb523c413c70ac43f@mail.gmail.com>
References: <828083e70804190453v35bb9753gb523c413c70ac43f@mail.gmail.com>
Message-ID: <1425C538-7F46-44B4-A12C-5FEEFDDDA074@ben-ward.co.uk>

On 19 Apr 2008, at 12:53, gabriele renzi wrote:
> looking at the kelkoo output, I see
>
> <li class="result hlisting cat-123 prod-1234 offer
> offer-manufacturer_products first" id="..">
>    <div class="information-container">
>     <ul class="information">
>      <li class="photo">
>        <a href="..">
>        <img alt="" src="..."/>
>        </a>
>      </li>
> ...
>
> Am I right in assuming that "photo" is an optional field of the
> Listing, which was formerly described as being a sub-filed of listing
>> item ?
> Furhermore, am I right in assuming that the parsing rule would be
>  get @src from  a IMG tag under .photo  ?

Alas, that is an error I made on Kelkoo. Under the current draft  
schema, ?photo? should be a property of ?item? and we got that wrong.  
I think we've got an open bug at Yahoo! to fix that, and I'll check  
the status of it on Monday.

I do wonder about allowing ?photo? under ?hListing?, just to loosen it  
up and maybe allow for photos the accompany the listing but which are  
not necessarily of the item itself, but I'm unsure, and would probably  
call that an optimisation. As such, shouldn't be considered until  
later in the process.

B
From thomasyde at yahoo.dk  Sat Apr 19 11:23:58 2008
From: thomasyde at yahoo.dk (Thomas Yde)
Date: Sat Apr 19 13:50:58 2008
Subject: [uf-new] Recipe development status
Message-ID: <5C3BB2AC-4788-4D1B-B9B1-96D7C90AB411@yahoo.dk>

I'm sorry, something went wrong in the formatting.

I hope this is better:

<div class="recipe">

	<h2 class="title">Title</h2>

	<div class="summary">This is a summary.</div>	

	<div class="author vcard">

		<span class="fn">anonymous</span>,

		<abbr class="dtpublished" title="20080419">April 19th, 2008</abbr>

	</div>

	<img src="url" class="photo" />	<p><span class="ingredient"><span  
class="quantity">100 g</span> <span class="name">name</span></span> and

	<span class="ingredient"><span class="quantity">1 dl</span> <span  
class="name">name</span> <span class="optional">(optional)</span></ 
span></p>

	<div class="method">

		<p>Step 1.</p>

		<p>Step 2.</p>

	</div>

</div>


Any comments or suggestions?


Ingredients and method could also be presented as lists:


<ul>

	<li class="ingredient"><span class="quantity">100 g</span> <span  
class="name">name</span></li>

	<li class="ingredient"><span class="quantity">1 dl</span> <span  
class="name">name</span> <span class="optional">(optional)</span></li>

</ul>

<ol class="method">

	<li>Step 1.</li>

	<li>Step 2.</li>

</ol>


In this case, would it be okay to mark the <ul> with a  
class="ingredients" and leave out class="ingredient" in the <li>'s?



-Thomas



From thomasyde at yahoo.dk  Sun Apr 20 04:39:02 2008
From: thomasyde at yahoo.dk (Thomas Yde)
Date: Sun Apr 20 04:39:08 2008
Subject: [uf-new] Recipe status
Message-ID: <43B018C5-18EC-4E13-9829-7835DFB0416E@yahoo.dk>

I tried to post this yesterday, but it didn't work so now I'll try  
again:

Development of the recipe format seems to be paused due to the  
(possible?) dependency on a measure format. But I see no reason why  
development of the format can't continue while measure is completed.

I duggest that we sum up what we can agree on so far:

1) The recipe microformat is designed for the mark-up of instructions  
for creating meals, drinks or food-based items. Other uses are  
outside the 80/20.

2) recipe should include the following properties:

* Title - Required
* Summary - Optional
* Author (hCard) - Optional
* Date published - Optional
* Photo(s) - Optional
* Ingredient(s)
	- Quantity - Optional
	- Name - Required
	- Optionality - Optional
	- Preparation Notes - Optional
* Method - Repuired

Also, there has been consensus in previous mailing-list posts that  
the following properties should be included:

* License (rel-license) - Optional
* Tags (rel-tags) - Optional

Can we include these in the property list on the recipe-brainstorm page?

Once we have a (kind of) final list of properties we can start to  
discuss what the actual markup would look like (is this what you call  
a 'strawman'?). My suggestions:

TITLE: class="title"

SUMMARY: class="summary"

AUTHOR+DATE PUBLISHED: class="fn" and class="dtpublished" inside a  
class="author vcard" as seen in hReview

PHOTO: an image with class="photo"

INGREDIENT(S): Sugsestion: If class="ingredients" (note: plural) is  
found on an element, class="ingredient" (nota: singular) is  
automatically implied on all its children. (As suggested on the  
recipe-brainstorm page).
Otherwise: class="ingredient" containing the following:

	QUANTITY: class="quantity". Question: Should this be split up to  
class="value" and class="unit" to be compatible with measure?

	NAME: class="name". Question: Should we rename this to class="item"  
to reuse the classnames of other formats and to be compatible with  
measure?

	OPTIONALITY: class="optional". I imagine something like this: <span  
class="optional">Your text</span>. Its absence should imply that the  
ingredient is required.

	PREPARATION NOTE: class="preparation-note"? I don't really think  
this is necessary. Couldn't it just be ordinary text inside the  
class="ingredient"?

METHOD: class="method". OK to make this a list but the list items  
should not be marked as method-steps. That's just POSH.

LICENSE: a link with rel="license".

TAGS: links with rel="tag".

Feel free to make any comments or suggestions.


-Thomas

From mail at tobyinkster.co.uk  Sun Apr 20 08:02:43 2008
From: mail at tobyinkster.co.uk (Toby A Inkster)
Date: Sun Apr 20 08:02:50 2008
Subject: [uf-new] Recipe status
Message-ID: <2F6ACB7C-31F8-444F-A6D2-857E3BE40C26@tobyinkster.co.uk>

I suggest that (where there is an overlap) we take class names from  
hAtom. This will allow easy overlapping between the formats for pages  
that feature a collection of recipes. e.g.

	<div class="hatom hrecipe">
		...
	</div>

even, say:

	<div class="hatom hrecipe hslice">
		...
	</div>

For Internet Explorer 8 fun!

So, as amendments to Thomas' proposal, I'd like to see:

	* Replace class="title" with class="entry-title"
	* Replace class="summary" with class="entry-summary"
	* Replace class="dtpublished" with class="published"

I realise you've already tried to take class names from hReview, but  
I think hAtom is a better match. Other than that, I like the schema  
proposed.

Regarding the relationship with the measure microformat, which I've  
been trying to push forward with a bit (I wrote most of the current  
draft schema), I don't think we need to wait for it. We should  
basically say that the class="quantity" element contains a free-form  
string. For any future parsers that do implement a measurement  
microformat, then a bit of mix and match will be perfectly acceptable  
-- but parsers which understand hrecipe and not hmeasure can just  
interpret the quantity as a string and that should be considered  
acceptable behaviour. So in short, we *allow* for a future  
measurement microformat to optionally be hooked in to hrecipe, but in  
general we just treat quantities as a string.

	<li class="ingredient hmeasure">
		<span class="quantity">
			<span class="value">2</span>
			<span class="unit">tbsp</span>
		</span>
		<span class="item">parsley</span>
		<span class="preparation-note">(chopped)</span>
	</li>

would be parsed by an hrecipe aware parser as:

	Ingredient:
		Quantity: 2 tbsp
		Item: parsley
		Preparation Note: (chopped)

and by an hmeasure aware parser as:

	Measurement:
		Value: 2
		Unit: tbsp
		Item: parsley

A parser aware of both could combine this information logically.

Also, I'm beginning to think that class="value" is a poor choice of  
class name for hmeasure, given its "special behaviour" in value  
excerpting. Should it be class="num", class="val" or something?

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>



From thomasyde at yahoo.dk  Sun Apr 20 08:42:57 2008
From: thomasyde at yahoo.dk (Thomas Yde)
Date: Sun Apr 20 08:43:03 2008
Subject: [uf-new] Recipe status
In-Reply-To: <2F6ACB7C-31F8-444F-A6D2-857E3BE40C26@tobyinkster.co.uk>
References: <2F6ACB7C-31F8-444F-A6D2-857E3BE40C26@tobyinkster.co.uk>
Message-ID: <63F23875-3CA4-49AD-8AB7-FE4A4B6EB0AE@yahoo.dk>

Toby A Inkster wrote:

> I suggest that (where there is an overlap) we take class names from  
> hAtom. This will allow easy overlapping between the formats for  
> pages that feature a collection of recipes. e.g.
>
> 	<div class="hatom hrecipe">
> 		...
> 	</div>
>
> even, say:
>
> 	<div class="hatom hrecipe hslice">
> 		...
> 	</div>
>
> For Internet Explorer 8 fun!
>
> So, as amendments to Thomas' proposal, I'd like to see:
>
> 	* Replace class="title" with class="entry-title"
> 	* Replace class="summary" with class="entry-summary"
> 	* Replace class="dtpublished" with class="published"
>
> I realise you've already tried to take class names from hReview,  
> but I think hAtom is a better match. Other than that, I like the  
> schema proposed.

Reusing class names from hatom seems logical to me as recipes have  
more in common with that format than hreview.

> Regarding the relationship with the measure microformat, which I've  
> been trying to push forward with a bit (I wrote most of the current  
> draft schema), I don't think we need to wait for it. We should  
> basically say that the class="quantity" element contains a free- 
> form string. For any future parsers that do implement a measurement  
> microformat, then a bit of mix and match will be perfectly  
> acceptable -- but parsers which understand hrecipe and not hmeasure  
> can just interpret the quantity as a string and that should be  
> considered acceptable behaviour. So in short, we *allow* for a  
> future measurement microformat to optionally be hooked in to  
> hrecipe, but in general we just treat quantities as a string.
>
> 	<li class="ingredient hmeasure">
> 		<span class="quantity">
> 			<span class="value">2</span>
> 			<span class="unit">tbsp</span>
> 		</span>
> 		<span class="item">parsley</span>
> 		<span class="preparation-note">(chopped)</span>
> 	</li>
>
> would be parsed by an hrecipe aware parser as:
>
> 	Ingredient:
> 		Quantity: 2 tbsp
> 		Item: parsley
> 		Preparation Note: (chopped)
>
> and by an hmeasure aware parser as:
>
> 	Measurement:
> 		Value: 2
> 		Unit: tbsp
> 		Item: parsley
>
> A parser aware of both could combine this information logically.

I agree that hmeasure can eventually be hooked into hrecipe and that  
we don't need to wait for hmeasure.

> Also, I'm beginning to think that class="value" is a poor choice of  
> class name for hmeasure, given its "special behaviour" in value  
> excerpting. Should it be class="num", class="val" or something?

Why do you think 'value' is a poor class name? Can you elaborate a  
bit on the "special behaviour"?


-Thomas

From mail at tobyinkster.co.uk  Sun Apr 20 14:50:37 2008
From: mail at tobyinkster.co.uk (Toby A Inkster)
Date: Sun Apr 20 15:07:38 2008
Subject: [uf-new] Recipe status
Message-ID: <579764D8-6104-4A79-8BA0-0C06EF715635@tobyinkster.co.uk>

Thomas Yde wrote:

> Why do you think 'value' is a poor class name? Can you elaborate a
> bit on the "special behaviour"?

http://microformats.org/wiki/hcard-parsing#Value_excerpting

So assuming that value excerpting (a shared design pattern used by  
most other compound microformats) is allowed in hrecipe, then my  
previous example:

	<li class="ingredient hmeasure">
		<span class="quantity">
			<span class="value">2</span>
			<span class="unit">tbsp</span>
		</span>
		<span class="item">parsley</span>
		<span class="preparation-note">(chopped)</span>
	</li>

It would be parsed by an hRecipe-aware agent (but without any special  
knowledge of hMeasure) as:

	Ingredient:
		Quantity: 2
		Item: Parsley
		Preparation Note: (chopped)

Note that the unit ("tbsp") is absent, because value-excerpting is  
applied to the quantity. That's why I feel that "value" is the wrong  
class name to use for the numeric part of the measurement in  
hmeasure. Perhaps "mag" (short for "magnitude") encompasses the  
meaning just as well, without having to worry about value excerpting?

That said it is the intention of my hmeasure schema that explicitly  
marking up the value and unit is not required in the vast majority of  
cases. So the following ought to avoid the value issue and parse  
properly using both the hmeasure and hrecipe microformats:

	<li class="ingredient">
		<span class="hmeasure">
			<span class="quantity">2 tbsp</span>
			<span class="item">parsley</span>
		</span>
		<span class="preparation-note">(chopped)</span>
	</li>

Becase according to hmeasure minimisation in the draft spec, the  
measurement doesn't have a value or unit, so minimisation is  
employed: the node contents (except the explicitly marked up "item")  
are taken to be the value and unit.

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>



From thomasyde at yahoo.dk  Mon Apr 21 02:07:41 2008
From: thomasyde at yahoo.dk (Thomas Yde)
Date: Mon Apr 21 02:07:51 2008
Subject: [Bulk] [uf-new] Recipe status
In-Reply-To: <579764D8-6104-4A79-8BA0-0C06EF715635@tobyinkster.co.uk>
References: <579764D8-6104-4A79-8BA0-0C06EF715635@tobyinkster.co.uk>
Message-ID: <3A6921AC-3869-4697-9693-5C82B5992621@yahoo.dk>

I see the problem with value excerpting but I don't have any  
suggestions for a solution or a better name right now.

BTW, in your example, wouldn't it be easier to just include the  
'hmeasure' class in the <li> like this:

	<li class="ingredient hmeasure">
		...
	</li>

Would an hmeasure-aware agent be able to just ignore preparation-note?

Also, I'm thinking that renaming 'preparation-note' to just 'note'  
would make it more useful for things like color and size?


-Thomas

From thomasyde at yahoo.dk  Tue Apr 22 10:45:41 2008
From: thomasyde at yahoo.dk (Thomas Yde)
Date: Tue Apr 22 10:48:09 2008
Subject: [uf-new] Recipe status
In-Reply-To: <3A6921AC-3869-4697-9693-5C82B5992621@yahoo.dk>
References: <579764D8-6104-4A79-8BA0-0C06EF715635@tobyinkster.co.uk>
	<3A6921AC-3869-4697-9693-5C82B5992621@yahoo.dk>
Message-ID: <0B3AC919-2A2A-4A0C-BD31-8FD5CE1B062A@yahoo.dk>

Thomas Yde wrote:

> BTW, in your example, wouldn't it be easier to just include the  
> 'hmeasure' class in the <li> like this:

Oops! I now see that you did exacly that in your first example so  
that must be a "yes" :) Just forget about it...

Looking at the recipe-examples (http://microformats.org/wiki/recipe- 
examples), I realise that we should have properties for "number of  
servings" (class name "servings"?) and preparation time (class name  
"preparation-time"?). In a previous mailing-list discussion (http:// 
microformats.org/discuss/mail/microformats-new/2007-September/ 
000864.html), the consensus was that they should be included.


-Thomas

From Michael.Smethurst at bbc.co.uk  Wed Apr 23 02:34:18 2008
From: Michael.Smethurst at bbc.co.uk (Michael Smethurst)
Date: Wed Apr 23 02:34:22 2008
Subject: [uf-new] grddl questions
Message-ID: <C434C12A.B80B%Michael.Smethurst@bbc.co.uk>

Hello!

Just a couple of questions about using grddl on microformatted pages:

- if some pages on a site contain grddlable ufs and some don't but they all
share a common layout / document head, does it break things if you always
include grddl profile and transform link? From the documentation adding the
profile "denote[s] that [the] document contains GRDDL metadata" which
wouldn't always be true in this case. I assume that's the wrong thing to do
here...

- if you're planning to provide all the data in the page (and more) as rdf
xml is there any point in making the html grddlable?

Thanks
Michael


http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
					
From msporny at digitalbazaar.com  Wed Apr 23 08:06:09 2008
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Wed Apr 23 09:26:06 2008
Subject: [uf-new] grddl questions
In-Reply-To: <C434C12A.B80B%Michael.Smethurst@bbc.co.uk>
References: <C434C12A.B80B%Michael.Smethurst@bbc.co.uk>
Message-ID: <480F5061.8040002@digitalbazaar.com>

Michael Smethurst wrote:
> - if some pages on a site contain grddlable ufs and some don't but they all
> share a common layout / document head, does it break things if you always
> include grddl profile and transform link? 

Technically, it shouldn't break anything, but that doesn't mean you
should be haphazard with the way you use GRDDL profiles on your pages.

In other words - it's frowned upon, but that's not going to stop people
from being sloppy.

> From the documentation adding the
> profile "denote[s] that [the] document contains GRDDL metadata" which
> wouldn't always be true in this case. I assume that's the wrong thing to do
> here...

You should only put a GRDDL profile on a page that actually contains
GRDDL metadata.

> - if you're planning to provide all the data in the page (and more) as rdf
> xml is there any point in making the html grddlable?

That depends on which use-case you have in mind. The better question to
ask is "Do you expect there to be GRDDL transform engines visiting the
page that don't understand RDF XML or RDFa?". If the answer to that
question is "Yes", then you will want to make the HTML GRDDL-able.

-- manu

From lee.jordan at gmail.com  Wed Apr 23 08:19:17 2008
From: lee.jordan at gmail.com (Lee Jordan)
Date: Wed Apr 23 12:43:05 2008
Subject: [uf-new] Airport Codes
Message-ID: <a2d985370804230819t2aebe34dl990eaf329fe654c0@mail.gmail.com>

Hi Guys,

Just had a thought while working on a travel website about a
microformat to mark out airport codes and thought the abbr design
pattern fits well with this. Travel sites will sometimes list the
airport code somewhere along a booking process, often without
expanding the abbreviation with the right HTML. Can I throw out a new
macro microformat which could be included inside the geo mF? Travel
websites like Trippit.com could mark up an airport with its three
letter code and the airports geographic location too with the geo mF.

< abbr title="Birmingham International Airport" class="airport-code"
>BHX< /abbr>

I can imagine in the future a super travel search engine, which will
know where your local airport is and thread through holiday deals with
flights going from your locality.

I'm thinking of marking up ABTA and ATOL logos with some kind of mF,
perhaps in the alt text of a logo, accessibility wise you'd need to
put the ABTA number from the logo into the alt text something because
of the text being in the image like < img src="logos/abta.png"
class="accreditation abta" alt="v4563" /> Anyone any pointers as to
travel related microformats? an "accreditation" class would be useful
for other things like accreditation corgi for Gas companies.

Regards
Lee

-- 
HTML | CSS | Javascript
http://www.leejordan.org.uk
From mail at tobyinkster.co.uk  Wed Apr 23 15:54:42 2008
From: mail at tobyinkster.co.uk (Toby A Inkster)
Date: Wed Apr 23 15:54:49 2008
Subject: [uf-new] Airport Codes
Message-ID: <AA5EED08-09DA-40DD-BEDE-4A665B526226@tobyinkster.co.uk>

Lee Jordan wrote:

> I can imagine in the future a super travel search engine, which will
> know where your local airport is and thread through holiday deals with
> flights going from your locality.

For that you'd need to mark up more than just airport codes. You'd  
need to know whether the flight was *from* the airport or *to* the  
airport. You'd probably want to know the price, the date and time,  
perhaps the airline, and the contact details for buying a ticket.  
Basically you'd need a microformat for marking up a transport ticket  
that is for sale. The existing hListing microformat will get you half  
way there - you'd just need to add some transport-specific properties.

I wouldn't restrict it to airports if I were you - journeys by sea,  
road and rail should be easy to cover too. UN/LOCODE provides a good  
place to start with for standardised alphanumeric location codes.

> I'm thinking of marking up ABTA and ATOL logos with some kind of mF,
> perhaps in the alt text of a logo, accessibility wise you'd need to
> put the ABTA number from the logo into the alt text something because
> of the text being in the image like < img src="logos/abta.png"
> class="accreditation abta" alt="v4563" />

You should start with hCard and see if it is sufficient for your  
needs. Only if there's something useful that you can't do with hCard  
should you consider extending it.

<div class="vcard">
	<span class="fn org">My Travel Agency</span>
	<img class="note" src="logos/abta.png" alt="ABTA accreditation v4563.">
</div>

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>



From thomasyde at yahoo.dk  Sat Apr 26 09:02:25 2008
From: thomasyde at yahoo.dk (Thomas Yde)
Date: Sat Apr 26 09:02:31 2008
Subject: [uf-new] Recipe status
In-Reply-To: <2F6ACB7C-31F8-444F-A6D2-857E3BE40C26@tobyinkster.co.uk>
References: <2F6ACB7C-31F8-444F-A6D2-857E3BE40C26@tobyinkster.co.uk>
Message-ID: <BB8302C7-9AC9-45D2-ADFF-25DEBCED15BD@yahoo.dk>

Toby A Inkster wrote:

> So, as amendments to Thomas' proposal, I'd like to see:
>
> 	* Replace class="title" with class="entry-title"
> 	* Replace class="summary" with class="entry-summary"
> 	* Replace class="dtpublished" with class="published"

There might be an issue here:

What if I want to make an hAtom entry containing a recipe with a  
different title and summay, e.g.;

<div class="hentry">
	<h1 class="entry-title">Blog post title</h1>
	<p class="entry-summary">Blog post summary</p>
	...
	<div class="hrecipe">
		<h2 class="entry-title">Recipe title</h2>
		<p class="entry-summary">Recipe summary</p>
		...
	</div>
</div>

How would an hAtom agent handle this?

-Thomas

From scott at makedatamakesense.com  Sat Apr 26 09:58:33 2008
From: scott at makedatamakesense.com (Scott Reynen)
Date: Sat Apr 26 09:58:40 2008
Subject: [uf-new] Recipe status
In-Reply-To: <BB8302C7-9AC9-45D2-ADFF-25DEBCED15BD@yahoo.dk>
References: <2F6ACB7C-31F8-444F-A6D2-857E3BE40C26@tobyinkster.co.uk>
	<BB8302C7-9AC9-45D2-ADFF-25DEBCED15BD@yahoo.dk>
Message-ID: <2121A12F-845F-4110-9FE1-60A5B43B246E@makedatamakesense.com>

On Apr 26, 2008, at 10:02 AM, Thomas Yde wrote:
> Toby A Inkster wrote:
>
>> So, as amendments to Thomas' proposal, I'd like to see:
>>
>> 	* Replace class="title" with class="entry-title"
>> 	* Replace class="summary" with class="entry-summary"
>> 	* Replace class="dtpublished" with class="published"
>
> There might be an issue here:
>
> What if I want to make an hAtom entry containing a recipe with a  
> different title and summay, e.g.;
>
> <div class="hentry">
> 	<h1 class="entry-title">Blog post title</h1>
> 	<p class="entry-summary">Blog post summary</p>
> 	...
> 	<div class="hrecipe">
> 		<h2 class="entry-title">Recipe title</h2>
> 		<p class="entry-summary">Recipe summary</p>
> 		...
> 	</div>
> </div>
>
> How would an hAtom agent handle this?

This is why we need mfo [1].  What typically happens when we see a  
problem like this is we use sub-optimal markup to avoid the problem  
before it actually occurs in real-world publishing.  I think this is a  
mistake.  Instead, I suggest we use markup that makes sense, and  
address this kind of parsing problem if/when it actually comes up in  
practice, e.g. by applying mfo in parsers.

[1] http://microformats.org/wiki/mfo

--
Scott Reynen
MakeDataMakeSense.com


From mail at tobyinkster.co.uk  Sat Apr 26 15:01:40 2008
From: mail at tobyinkster.co.uk (Toby A Inkster)
Date: Sat Apr 26 15:01:57 2008
Subject: [uf-new] Recipe status
Message-ID: <C451DEA8-A29B-47CB-AFE3-12CBD43A07D8@tobyinkster.co.uk>

Scott Reynen wrote:

> This is why we need mfo [1].

Indeed. mfo is important for many reasons - more work should be put  
into this pattern. More parsers should make an effort to support it.  
Cognition has supported it since alpha4 and I've documented my  
algorithm for safely handling nested microformats on the wiki  
(somewhere) and here:

http://buzzword.org.uk/cognition/uf-plus.html#mfo

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>



From derrick at pallas.us  Sat Apr 26 15:13:43 2008
From: derrick at pallas.us (Derrick Lyndon Pallas)
Date: Sat Apr 26 15:13:44 2008
Subject: [uf-new] Recipe status
In-Reply-To: <2121A12F-845F-4110-9FE1-60A5B43B246E@makedatamakesense.com>
References: <2F6ACB7C-31F8-444F-A6D2-857E3BE40C26@tobyinkster.co.uk>	<BB8302C7-9AC9-45D2-ADFF-25DEBCED15BD@yahoo.dk>
	<2121A12F-845F-4110-9FE1-60A5B43B246E@makedatamakesense.com>
Message-ID: <4813A917.8070006@pallas.us>

Wow! I didn't expect to hear about mfo again until September. Maybe its 
time has come! A real-world parser: ~D


Scott Reynen wrote:
> This is why we need mfo [1].  What typically happens when we see a 
> problem like this is we use sub-optimal markup to avoid the problem 
> before it actually occurs in real-world publishing.  I think this is a 
> mistake.  Instead, I suggest we use markup that makes sense, and 
> address this kind of parsing problem if/when it actually comes up in 
> practice, e.g. by applying mfo in parsers.
>
> [1] http://microformats.org/wiki/mfo

From danbri at danbri.org  Mon Apr 28 05:01:58 2008
From: danbri at danbri.org (Dan Brickley)
Date: Mon Apr 28 05:02:05 2008
Subject: [uf-new] Recipe status
In-Reply-To: <4813A917.8070006@pallas.us>
References: <2F6ACB7C-31F8-444F-A6D2-857E3BE40C26@tobyinkster.co.uk>	<BB8302C7-9AC9-45D2-ADFF-25DEBCED15BD@yahoo.dk>	<2121A12F-845F-4110-9FE1-60A5B43B246E@makedatamakesense.com>
	<4813A917.8070006@pallas.us>
Message-ID: <4815BCB6.5040208@danbri.org>

Derrick Lyndon Pallas wrote:
> Wow! I didn't expect to hear about mfo again until September. Maybe its 
> time has come! A real-world parser: ~D


I hadn't heard of mfo, but the use case,

"E.g. you might put a <span class="vcard mfo"> deep inside a <span 
class="vevent">, and not want the categories/tags of the hCard 
accidentally parsed into the hCalendar event."

...is pretty well motivated from an RDFy/SemWeb perspective, since we're 
all about mixing vocabs. The mfo sketch suggests progress towards having 
it be clearer which entity some properties are being attached to, 
without each parser needing hardcoded knowledge of each and every 
vocabulary. Cool stuff!

cheers,

dan

> Scott Reynen wrote:
>> This is why we need mfo [1].  What typically happens when we see a 
>> problem like this is we use sub-optimal markup to avoid the problem 
>> before it actually occurs in real-world publishing.  I think this is a 
>> mistake.  Instead, I suggest we use markup that makes sense, and 
>> address this kind of parsing problem if/when it actually comes up in 
>> practice, e.g. by applying mfo in parsers.
>>
>> [1] http://microformats.org/wiki/mfo
> 
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
> 
> 

From davidjanes at blogmatrix.com  Mon Apr 28 05:24:24 2008
From: davidjanes at blogmatrix.com (David Janes)
Date: Mon Apr 28 05:24:28 2008
Subject: [uf-new] Recipe status
In-Reply-To: <BB8302C7-9AC9-45D2-ADFF-25DEBCED15BD@yahoo.dk>
References: <2F6ACB7C-31F8-444F-A6D2-857E3BE40C26@tobyinkster.co.uk>
	<BB8302C7-9AC9-45D2-ADFF-25DEBCED15BD@yahoo.dk>
Message-ID: <21e523c20804280524o119b9c8pb98d8a3a6d9daa6@mail.gmail.com>

On Sat, Apr 26, 2008 at 12:02 PM, Thomas Yde <thomasyde@yahoo.dk> wrote:
>
> Toby A Inkster wrote:
>
>
> > So, as amendments to Thomas' proposal, I'd like to see:
> >
> >        * Replace class="title" with class="entry-title"
> >        * Replace class="summary" with class="entry-summary"
> >        * Replace class="dtpublished" with class="published"
> >
>
> There might be an issue here:
>
> What if I want to make an hAtom entry containing a recipe with a different title and summay, e.g.;
>
> <div class="hentry">
>        <h1 class="entry-title">Blog post title</h1>
>        <p class="entry-summary">Blog post summary</p>
>        ...
>        <div class="hrecipe">
>                <h2 class="entry-title">Recipe title</h2>
>                <p class="entry-summary">Recipe summary</p>
>                ...
>        </div>
> </div>
>
> How would an hAtom agent handle this?
>

Use 'blockquote' around the recipe, which is 'mfo' automatically for hAtom

-- 
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://www.onaswarm.com
From brian.suda at gmail.com  Mon Apr 28 05:47:39 2008
From: brian.suda at gmail.com (Brian Suda)
Date: Mon Apr 28 05:47:44 2008
Subject: [uf-new] Recipe status
In-Reply-To: <BB8302C7-9AC9-45D2-ADFF-25DEBCED15BD@yahoo.dk>
References: <2F6ACB7C-31F8-444F-A6D2-857E3BE40C26@tobyinkster.co.uk>
	<BB8302C7-9AC9-45D2-ADFF-25DEBCED15BD@yahoo.dk>
Message-ID: <21e770780804280547k192ebc3ldfcfa43fa36814fa@mail.gmail.com>

2008/4/26 Thomas Yde <thomasyde@yahoo.dk>:
>  What if I want to make an hAtom entry containing a recipe with a different
> title and summay, e.g.;
>
>  <div class="hentry">
>         <h1 class="entry-title">Blog post title</h1>
>         <p class="entry-summary">Blog post summary</p>
>         ...
>         <div class="hrecipe">
>                 <h2 class="entry-title">Recipe title</h2>
>                 <p class="entry-summary">Recipe summary</p>
>                 ...
>         </div>
>  </div>
>
>  How would an hAtom agent handle this?

Properties that are singular (can only occur once) take only the first
instance. So in this example, the hEntry will find the title and
summary of the Blog post and ignore any subsequent instances. the
recipe will only find it's children of the recipe summary/title. In
this example, nothing more needs to be done to parse the information
correctly.

Any specific parsing type questions should be directed to the dev-list

-brian


-- 
brian suda
http://suda.co.uk
From mail at tobyinkster.co.uk  Mon Apr 28 05:49:19 2008
From: mail at tobyinkster.co.uk (Toby A Inkster)
Date: Mon Apr 28 05:49:31 2008
Subject: [uf-new] Recipe status
Message-ID: <866AF50C-D885-4C24-9313-771E57F254AD@tobyinkster.co.uk>

David Janes wrote:

> Use 'blockquote' around the recipe, which is 'mfo' automatically  
> for hAtom

In many cases this stretches the semantics of the <blockquote> element.

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>



From davidjanes at blogmatrix.com  Mon Apr 28 06:03:31 2008
From: davidjanes at blogmatrix.com (David Janes)
Date: Mon Apr 28 06:03:34 2008
Subject: [uf-new] Recipe status
In-Reply-To: <866AF50C-D885-4C24-9313-771E57F254AD@tobyinkster.co.uk>
References: <866AF50C-D885-4C24-9313-771E57F254AD@tobyinkster.co.uk>
Message-ID: <21e523c20804280603h7f7e444emcd107ebfce599ab1@mail.gmail.com>

Really? And I thought it was well researched and entirely consistent
with the way blog and other posts were being used. Perhaps you'd like
to show a real world example where there's a blockquote inside of
microcontent where you'd like hAtom to interpret the contents as being
anything other than entry-content or entry-summary.

On Mon, Apr 28, 2008 at 8:49 AM, Toby A Inkster <mail@tobyinkster.co.uk> wrote:
> David Janes wrote:
>
>
> > Use 'blockquote' around the recipe, which is 'mfo' automatically for hAtom
> >
>
>  In many cases this stretches the semantics of the <blockquote> element.
>
>  --
>  Toby A Inkster
>  <mailto:mail@tobyinkster.co.uk>
>  <http://tobyinkster.co.uk>
>
>
>
>  _______________________________________________
>  microformats-new mailing list
>  microformats-new@microformats.org
>  http://microformats.org/mailman/listinfo/microformats-new
>



-- 
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://www.onaswarm.com
From mail at tobyinkster.co.uk  Mon Apr 28 08:07:28 2008
From: mail at tobyinkster.co.uk (Toby A Inkster)
Date: Mon Apr 28 10:35:26 2008
Subject: [uf-new] Recipe status
Message-ID: <B579B58A-7A4D-458B-831B-3ED985E1FF36@tobyinkster.co.uk>

David Janes wrote:

> Really? And I thought it was well researched and entirely consistent
> with the way blog and other posts were being used. Perhaps you'd like
> to show a real world example where there's a blockquote inside of
> microcontent where you'd like hAtom to interpret the contents as being
> anything other than entry-content or entry-summary.

I was rather thinking of the inverse of that: i.e., situations where  
you want an hAtom parser to ignore the contents of an element, but  
the use of <blockquote> would be inappropriate (because the content  
in question is not a quote).

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>



From davidjanes at blogmatrix.com  Mon Apr 28 10:53:31 2008
From: davidjanes at blogmatrix.com (David Janes)
Date: Mon Apr 28 10:53:33 2008
Subject: [uf-new] Recipe status
In-Reply-To: <B579B58A-7A4D-458B-831B-3ED985E1FF36@tobyinkster.co.uk>
References: <B579B58A-7A4D-458B-831B-3ED985E1FF36@tobyinkster.co.uk>
Message-ID: <21e523c20804281053x777d13b6i5636e3896730f036@mail.gmail.com>

Ah yes ... we're both quite right!

On Mon, Apr 28, 2008 at 11:07 AM, Toby A Inkster <mail@tobyinkster.co.uk> wrote:
> David Janes wrote:
>
>
> > Really? And I thought it was well researched and entirely consistent
> > with the way blog and other posts were being used. Perhaps you'd like
> > to show a real world example where there's a blockquote inside of
> > microcontent where you'd like hAtom to interpret the contents as being
> > anything other than entry-content or entry-summary.
> >
>
>  I was rather thinking of the inverse of that: i.e., situations where you
> want an hAtom parser to ignore the contents of an element, but the use of
> <blockquote> would be inappropriate (because the content in question is not
> a quote).
>
>  --
>  Toby A Inkster
>  <mailto:mail@tobyinkster.co.uk>
>  <http://tobyinkster.co.uk>
>
>
>
>  _______________________________________________
>  microformats-new mailing list
>  microformats-new@microformats.org
>  http://microformats.org/mailman/listinfo/microformats-new
>



-- 
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://www.onaswarm.com