From fberriman at gmail.com  Mon Oct  1 08:53:32 2007
From: fberriman at gmail.com (Frances Berriman)
Date: Mon Oct  1 08:53:36 2007
Subject: [uf-new] Internet radio and TV
In-Reply-To: <6.2.0.14.2.20070925154427.02df1fc8@pop3>
References: <6.2.0.14.2.20070925154427.02df1fc8@pop3>
Message-ID: <e86992a40710010853o199eb8e8w683a9fa47fee328c@mail.gmail.com>

On 25/09/2007, Chris Newell <chris.newell@rd.bbc.co.uk> wrote:
> I'm interested in exploring how Internet radio and TV stations could be defined semantically.
>
> As hAudio appears targeted at individual recordings and collections of content I'm not sure it would be beneficial to the development process, or to the end-users, to add additional complexity in order to support Internet radio.
>
> Looking at the station listings out there on the web, there doesn't appear to be much difference between the metadata provided for radio and TV stations but there is a lot in common e.g. streams are often available at different bitrates or using different codecs.
>
> Does anyone else have an interest or thoughts in this area?
>
> Chris

It's an interesting concept and worth exploring and I see there's some
stuff up on the wiki about it that you've started.  Might be
worthwhile to see how much can be done with a mixture of the audio
work, hAtom (for syndication) and hCalendar (for scheduling - time of
air if it is time sensitive/limited broadcast)?


-- 
Frances Berriman
http://fberriman.com
From gl at brixlogic.com  Mon Oct  1 09:57:01 2007
From: gl at brixlogic.com (Guillaume Lebleu)
Date: Mon Oct  1 09:57:09 2007
Subject: [uf-new] Currency brainstorming
In-Reply-To: <A8lqGFrPPp$GFwo3@pigsonthewing.org.uk>
References: <615160.30567.qm@web54108.mail.re2.yahoo.com>
	<A8lqGFrPPp$GFwo3@pigsonthewing.org.uk>
Message-ID: <470126DD.7000009@brixlogic.com>

Andy Mabbett wrote:
> To apply a date, we could simply use hCalendar:
>
>     <div class="vevent">
>       <span class="description">
>         <span class="summary">
>           The last Monet painting to be auctioned
>         </span>
>         fetched
>         <abbr class="currency" title="USD95M">$95 million</abbr>
>         in
>         <span class="dtstart>2005</span>
>       </span>
>     </div>
>   
+1

Addresses the problem of historical money amounts without making the 
date a property/subclass of currency/hmoney class.

Guillaume

From chris.newell at rd.bbc.co.uk  Tue Oct  2 01:18:45 2007
From: chris.newell at rd.bbc.co.uk (Chris Newell)
Date: Tue Oct  2 01:18:51 2007
Subject: [uf-new] Internet radio and TV examples
Message-ID: <6.2.0.14.2.20071002091252.03c74eb8@pop3>

I've started a wiki page to collect Internet radio and TV examples: http://microformats.org/wiki/broadcast-examples

Please feel free to contribute more examples if you have them. I will try to raise awareness within the broadcasting industry.

Chris
_______________________ 
Chris Newell
Lead Technologist 
BBC Research

From chris.newell at rd.bbc.co.uk  Tue Oct  2 01:26:54 2007
From: chris.newell at rd.bbc.co.uk (Chris Newell)
Date: Tue Oct  2 01:26:58 2007
Subject: [uf-new] Internet radio and TV
In-Reply-To: <e86992a40710010853o199eb8e8w683a9fa47fee328c@mail.gmail.co
 m>
References: <6.2.0.14.2.20070925154427.02df1fc8@pop3>
	<e86992a40710010853o199eb8e8w683a9fa47fee328c@mail.gmail.com>
Message-ID: <6.2.0.14.2.20071002090751.02e92ce8@pop3>

Frances Berriman wrote:
At 16:53 01/10/2007, you wrote:
>On 25/09/2007, Chris Newell <chris.newell@rd.bbc.co.uk> wrote:
>> I'm interested in exploring how Internet radio and TV stations could be defined semantically.
>>
>> As hAudio appears targeted at individual recordings and collections of content I'm not sure it would be beneficial to the development process, or to the end-users, to add additional complexity in order to support Internet radio.
>>
>> Looking at the station listings out there on the web, there doesn't appear to be much difference between the metadata provided for radio and TV stations but there is a lot in common e.g. streams are often available at different bitrates or using different codecs.
>>
>> Does anyone else have an interest or thoughts in this area?
>>
>> Chris
>
>It's an interesting concept and worth exploring and I see there's some
>stuff up on the wiki about it that you've started.  Might be
>worthwhile to see how much can be done with a mixture of the audio
>work, hAtom (for syndication) and hCalendar (for scheduling - time of
>air if it is time sensitive/limited broadcast)?

Syndication may be more appropriate to hAudio / hVideo as currently proposed but I agree entirely with the latter idea for real-time streams - something similar was proposed during the media-info discussion before it got bogged down due to the broadness of the overall scope.

Chris

_______________________ 
Chris Newell
Lead Technologist 
BBC Research

From chris.newell at rd.bbc.co.uk  Wed Oct  3 01:39:21 2007
From: chris.newell at rd.bbc.co.uk (Chris Newell)
Date: Wed Oct  3 01:39:39 2007
Subject: [uf-new] Internet radio and TV brainstorming
Message-ID: <6.2.0.14.2.20071002164620.02e126f0@pop3>

I've started a brainstorming page for Internet radio and TV: http://microformats.org/wiki/broadcast-brainstorming

Please contribute any ideas you have in this area.

Chris
_______________________ 
Chris Newell
Lead Technologist 
BBC Research

From fberriman at gmail.com  Wed Oct  3 08:28:28 2007
From: fberriman at gmail.com (Frances Berriman)
Date: Wed Oct  3 08:28:33 2007
Subject: [uf-new] Recipe Examples- Any more?
Message-ID: <e86992a40710030828k17fe1cd1t6cb0083159f459d4@mail.gmail.com>

Ben Ward has kindly tidied the recipe-brainstorm[1] page to reflect
recent discussions we've had here.

Would any other interested parties take a look please and give us any feedback.

I think the first thing I'd like to do is query whether we feel the
examples[2] section of the work is complete enough to next discuss
commonalities and some of the proposed properties.

It does look to me like not that many, but I am feeling quite
confident that we're not going to find much more varied examples from
what's there given that our scope is to stick within food recipes
only.

Since I didn't conduct this research though, I'm keen to know other
people's feelings on it.

[1] http://microformats.org/wiki/recipe-brainstorming
[2]http://microformats.org/wiki/recipe-examples
-- 
Frances Berriman
http://fberriman.com
From mike at yarrt.com  Wed Oct  3 11:37:51 2007
From: mike at yarrt.com (Michael Walker)
Date: Wed Oct  3 11:38:12 2007
Subject: [uf-new] I propose a new microformat for poems.
Message-ID: <op.tzmwpdytjyd8jy@mikeslaptop>

Well, this is my first post to this mailing list and I thought i'd start  
by addressing a problem thats been annoying me for a while.

I can't seem to find a microformat for poetry. I often write poems and  
post them to my blog (http://blog.yarrt.com), and I sometimes wonder about  
the best way to code them. Below is the method I have thought of (with one  
of my poems as an example):

[Heading Text Here, possibly a <h1>, <h2>, etc, depending on the context]
<div class="poem">
   <p class="verse">
     Standing by the roadside,<br />
     A tall dark man,<br />
     Wore a long brown coat,<br />
     Stood in the rain.
   </p>
   <p class="verse">
     Explained he had no home,<br />
     Just travelled the country,<br />
     Sleeping on the streets,<br />
     Begging for his food.
   </p>
   <p class="verse">
     "Why is he helping me?",<br />
     "Where am I going?",<br />
     He must have wondered,<br />
     While stepping into the car.
   </p>
   <p class="verse">
     He seemed uneasy,<br />
     Not sure to trust me,<br />
     He had seem too much,<br />
     To trust people blindly.
   </p>
</div>

I would suggest marking it up with the following CSS rule:
div.poem p.verse{
   margin:10px;
}

Possibly with a border around the whole poem, but that is, of course,  
completely up to you.

What do you all think?
-- 
Michael Walker, Webmaster

From supercanadian at gmail.com  Wed Oct  3 11:58:11 2007
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Wed Oct  3 11:58:16 2007
Subject: [uf-new] I propose a new microformat for poems.
In-Reply-To: <op.tzmwpdytjyd8jy@mikeslaptop>
References: <op.tzmwpdytjyd8jy@mikeslaptop>
Message-ID: <84ce626f0710031158o3896c0c2m696621437a9c7d95@mail.gmail.com>

Hello Michael,

On 10/3/07, Michael Walker <mike@yarrt.com> wrote:
> Well, this is my first post to this mailing list and I thought i'd start
> by addressing a problem thats been annoying me for a while.
>
> I can't seem to find a microformat for poetry. I often write poems and
> post them to my blog (http://blog.yarrt.com), and I sometimes wonder about
> the best way to code them. Below is the method I have thought of (with one
> of my poems as an example):
>

[...]

> What do you all think?

This is an excellent example of POSH.

So... you this may be a case for POSH (Plain Old Semantic HTML),
instead of a Microformat.  Here's more info on POSH...

http://microformats.org/wiki/posh


Having said that... if there are others putting poems on the web
too... then there may be a case to come up with a common POSH format
-- a Microformat.  If that's the case then you may want to look at the
Microformat process...

http://microformats.org/wiki/process


See ya




-- 
    Charles Iliya Krempeaux, B.Sc. <http://ChangeLog.ca/>


                 Vlog Razor... Vlogging News
                    http://vlograzor.com/
From scott at makedatamakesense.com  Wed Oct  3 12:04:34 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Wed Oct  3 12:04:47 2007
Subject: [uf-new] I propose a new microformat for poems.
In-Reply-To: <op.tzmwpdytjyd8jy@mikeslaptop>
References: <op.tzmwpdytjyd8jy@mikeslaptop>
Message-ID: <579F2201-E9BC-4904-8B42-301DD899F5F7@makedatamakesense.com>

On Oct 3, 2007, at 12:37 PM, Michael Walker wrote:

> I can't seem to find a microformat for poetry. I often write poems  
> and post them to my blog (http://blog.yarrt.com), and I sometimes  
> wonder about the best way to code them. Below is the method I have  
> thought of (with one of my poems as an example):

Before we get into brainstorming, do you have some specific use cases  
in mind for such a microformat?  What problem are we tying to solve  
here?  If you haven't already, please read about the microformats  
process:

http://microformats.org/wiki/process

--
Scott Reynen
MakeDataMakeSense.com


From alexandrevandesande at gmail.com  Wed Oct  3 14:59:46 2007
From: alexandrevandesande at gmail.com (Alexandre Van de Sande)
Date: Wed Oct  3 14:59:49 2007
Subject: [uf-new] I propose a new microformat for poems.
In-Reply-To: <579F2201-E9BC-4904-8B42-301DD899F5F7@makedatamakesense.com>
References: <op.tzmwpdytjyd8jy@mikeslaptop>
	<579F2201-E9BC-4904-8B42-301DD899F5F7@makedatamakesense.com>
Message-ID: <8608a69a0710031459o271f4624lb4d75f81e25748b1@mail.gmail.com>

you mean a microformat for sonnets, or for haikus or Odes or Sestinas,
because Poetry is a broad term that defies an objective structure
needed by microformatting. And I agree with previous commenters that
this requires a problem.

On 10/3/07, Scott Reynen <scott@makedatamakesense.com> wrote:
> On Oct 3, 2007, at 12:37 PM, Michael Walker wrote:
>
> > I can't seem to find a microformat for poetry. I often write poems
> > and post them to my blog (http://blog.yarrt.com), and I sometimes
> > wonder about the best way to code them. Below is the method I have
> > thought of (with one of my poems as an example):
>
> Before we get into brainstorming, do you have some specific use cases
> in mind for such a microformat?  What problem are we tying to solve
> here?  If you haven't already, please read about the microformats
> process:
>
> http://microformats.org/wiki/process
>
> --
> Scott Reynen
> MakeDataMakeSense.com
>
>
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
>


-- 
Alexandre Van de Sande
www.wanderingabout.com
rio de janeiro

     ?

From andy at pigsonthewing.org.uk  Wed Oct  3 15:02:50 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Wed Oct  3 15:03:58 2007
Subject: [uf-new] I propose a new microformat for poems.
In-Reply-To: <op.tzmwpdytjyd8jy@mikeslaptop>
References: <op.tzmwpdytjyd8jy@mikeslaptop>
Message-ID: <OIKp7abKGBBHFw$f@pigsonthewing.org.uk>

In message <op.tzmwpdytjyd8jy@mikeslaptop>, Michael Walker
<mike@yarrt.com> writes

>I can't seem to find a microformat for poetry.

What would be the use-case? In other words, what would parsers (browsers
or browser plug-ins; other websites) do with poems marked up that way?

You should also look at the work which has been done on a proposed
"citation" microformat:

        <http://microformats.org/wiki/citation>

since a poem on a website is, effectively, cited.

Then you should compile examples of poems published on the web: what
data is commonly included?

You might find, for example, that most poems published are dated, or
cre4dit the author. But what else?

-- 
Andy Mabbett
From lorenzo.detomasi at gmail.com  Thu Oct  4 00:19:16 2007
From: lorenzo.detomasi at gmail.com (Lorenzo De Tomasi)
Date: Thu Oct  4 00:19:21 2007
Subject: [uf-new] Recipe Examples- Any more?
In-Reply-To: <e86992a40710030828k17fe1cd1t6cb0083159f459d4@mail.gmail.com>
References: <e86992a40710030828k17fe1cd1t6cb0083159f459d4@mail.gmail.com>
Message-ID: <5c2a5c380710040019p314c8b77tffacc4ce2d68a266@mail.gmail.com>

Look at http://www.cooker.net , one of the most advanced recipe
repository of recipes in Italy.
You can ask them, for their experience.
Have a good lunch! :-D

On 10/3/07, Frances Berriman <fberriman@gmail.com> wrote:

> It does look to me like not that many, but I am feeling quite
> confident that we're not going to find much more varied examples from
> what's there given that our scope is to stick within food recipes
> only.

-- 
Lorenzo De Tomasi
Designer multimodale
http://www.ipernico.it
http://www.isotype.org (in costruzione)
From fberriman at gmail.com  Thu Oct  4 01:26:29 2007
From: fberriman at gmail.com (Frances Berriman)
Date: Thu Oct  4 01:26:33 2007
Subject: [uf-new] Recipe Examples- Any more?
In-Reply-To: <5c2a5c380710040019p314c8b77tffacc4ce2d68a266@mail.gmail.com>
References: <e86992a40710030828k17fe1cd1t6cb0083159f459d4@mail.gmail.com>
	<5c2a5c380710040019p314c8b77tffacc4ce2d68a266@mail.gmail.com>
Message-ID: <e86992a40710040126v18dad605h2dd456f45d5153b@mail.gmail.com>

On 04/10/2007, Lorenzo De Tomasi <lorenzo.detomasi@gmail.com> wrote:
> Look at http://www.cooker.net , one of the most advanced recipe
> repository of recipes in Italy.
> You can ask them, for their experience.
> Have a good lunch! :-D

Interesting. My Italian isn't up to much, but I can figure it out.


-- 
Frances Berriman
http://fberriman.com
From andy at pigsonthewing.org.uk  Thu Oct  4 03:04:55 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Thu Oct  4 03:05:06 2007
Subject: [uf-new] I propose a new microformat for poems.
Message-ID: <3860.80.249.57.38.1191492295.squirrel@www.gradwell.com>

I wrote:

>you should compile examples of poems published on the web: what
>data is commonly included?

For example, note the example, marking up Dublin Core metadata about a
poem, at the top of page three of rfc2731:

    <http://www.ietf.org/rfc/rfc2731.txt>

-- 
Andy Mabbett
** via webmail **

From xblazox at gmail.com  Thu Oct  4 05:00:44 2007
From: xblazox at gmail.com (John Blazier)
Date: Thu Oct  4 05:00:54 2007
Subject: [uf-new] unsubscribe
In-Reply-To: <200710032200.l93M0BBS028103@microformats.org>
References: <200710032200.l93M0BBS028103@microformats.org>
Message-ID: <000c01c8067e$32a63b20$2102a8c0@blazo4akn0dki8>



John Blazier

834 Old Waterbury Road

Southbury, CT 06488

 

voice:  203-267-3328  fax:  203-267-3329

               cell:  203-841-9399

 

xblazox@gmail.com


-----Original Message-----
From: microformats-new-bounces@microformats.org
[mailto:microformats-new-bounces@microformats.org] On Behalf Of
microformats-new-request@microformats.org
Sent: Wednesday, October 03, 2007 6:00 PM
To: microformats-new@microformats.org
Subject: microformats-new Digest, Vol 9, Issue 1

Send microformats-new mailing list submissions to
	microformats-new@microformats.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://microformats.org/mailman/listinfo/microformats-new
or, via email, send a message with subject or body 'help' to
	microformats-new-request@microformats.org

You can reach the person managing the list at
	microformats-new-owner@microformats.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of microformats-new digest..."


Today's Topics:

   1. Money (aka Currency) and Measure test cases (Andy Mabbett)
   2. Re: Internet radio and TV (Frances Berriman)
   3. Re: Currency brainstorming (Guillaume Lebleu)
   4. Internet radio and TV examples (Chris Newell)
   5. Re: Internet radio and TV (Chris Newell)
   6. Internet radio and TV brainstorming (Chris Newell)
   7. Recipe Examples- Any more? (Frances Berriman)
   8. I propose a new microformat for poems. (Michael Walker)
   9. Re: I propose a new microformat for poems.
      (Charles Iliya Krempeaux)
  10. Re: I propose a new microformat for poems. (Scott Reynen)
  11. Re: I propose a new microformat for poems.
      (Alexandre Van de Sande)


----------------------------------------------------------------------

Message: 1
Date: Sat, 29 Sep 2007 20:20:18 +0100
From: Andy Mabbett <andy@pigsonthewing.org.uk>
Subject: [uf-new] Money (aka Currency) and Measure test cases
To: Microformats New <microformats-new@microformats.org>
Message-ID: <$pa1zSxyVq$GFwfX@pigsonthewing.org.uk>
Content-Type: text/plain;charset=us-ascii


I have put up some simple test cases for Money and Currency microformats
(using arbitrary class names), based on Taylor Cowan's model or working.

Should anyone like to try a testing them with a parser, please feel free
and comment on the results here. or on the wiki.

I have added some variations of spacing, ordering and capitalisation, so
we can decide whether we need to be strict or generous in what we allow.

        <http://www.westmidlandbirdclub.com/test/money.htm>

        <http://www.westmidlandbirdclub.com/test/measure.htm>

I'll be happy to add alternative examples, if anyone has any.

Enjoy!

-- 
Andy Mabbett


------------------------------

Message: 2
Date: Mon, 1 Oct 2007 16:53:32 +0100
From: "Frances Berriman" <fberriman@gmail.com>
Subject: Re: [uf-new] Internet radio and TV
To: "For discussion of new microformats."
	<microformats-new@microformats.org>
Message-ID:
	<e86992a40710010853o199eb8e8w683a9fa47fee328c@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On 25/09/2007, Chris Newell <chris.newell@rd.bbc.co.uk> wrote:
> I'm interested in exploring how Internet radio and TV stations could be
defined semantically.
>
> As hAudio appears targeted at individual recordings and collections of
content I'm not sure it would be beneficial to the development process, or
to the end-users, to add additional complexity in order to support Internet
radio.
>
> Looking at the station listings out there on the web, there doesn't appear
to be much difference between the metadata provided for radio and TV
stations but there is a lot in common e.g. streams are often available at
different bitrates or using different codecs.
>
> Does anyone else have an interest or thoughts in this area?
>
> Chris

It's an interesting concept and worth exploring and I see there's some
stuff up on the wiki about it that you've started.  Might be
worthwhile to see how much can be done with a mixture of the audio
work, hAtom (for syndication) and hCalendar (for scheduling - time of
air if it is time sensitive/limited broadcast)?


-- 
Frances Berriman
http://fberriman.com


------------------------------

Message: 3
Date: Mon, 01 Oct 2007 09:57:01 -0700
From: Guillaume Lebleu <gl@brixlogic.com>
Subject: Re: [uf-new] Currency brainstorming
To: "For discussion of new microformats."
	<microformats-new@microformats.org>
Message-ID: <470126DD.7000009@brixlogic.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Andy Mabbett wrote:
> To apply a date, we could simply use hCalendar:
>
>     <div class="vevent">
>       <span class="description">
>         <span class="summary">
>           The last Monet painting to be auctioned
>         </span>
>         fetched
>         <abbr class="currency" title="USD95M">$95 million</abbr>
>         in
>         <span class="dtstart>2005</span>
>       </span>
>     </div>
>   
+1

Addresses the problem of historical money amounts without making the 
date a property/subclass of currency/hmoney class.

Guillaume



------------------------------

Message: 4
Date: Tue, 02 Oct 2007 09:18:45 +0100
From: Chris Newell <chris.newell@rd.bbc.co.uk>
Subject: [uf-new] Internet radio and TV examples
To: <microformats-new@microformats.org>
Message-ID: <6.2.0.14.2.20071002091252.03c74eb8@pop3>
Content-Type: text/plain; charset="us-ascii"

I've started a wiki page to collect Internet radio and TV examples:
http://microformats.org/wiki/broadcast-examples

Please feel free to contribute more examples if you have them. I will try to
raise awareness within the broadcasting industry.

Chris
_______________________ 
Chris Newell
Lead Technologist 
BBC Research



------------------------------

Message: 5
Date: Tue, 02 Oct 2007 09:26:54 +0100
From: Chris Newell <chris.newell@rd.bbc.co.uk>
Subject: Re: [uf-new] Internet radio and TV
To: "For discussion of new microformats."
	<microformats-new@microformats.org>
Message-ID: <6.2.0.14.2.20071002090751.02e92ce8@pop3>
Content-Type: text/plain; charset="us-ascii"

Frances Berriman wrote:
At 16:53 01/10/2007, you wrote:
>On 25/09/2007, Chris Newell <chris.newell@rd.bbc.co.uk> wrote:
>> I'm interested in exploring how Internet radio and TV stations could be
defined semantically.
>>
>> As hAudio appears targeted at individual recordings and collections of
content I'm not sure it would be beneficial to the development process, or
to the end-users, to add additional complexity in order to support Internet
radio.
>>
>> Looking at the station listings out there on the web, there doesn't
appear to be much difference between the metadata provided for radio and TV
stations but there is a lot in common e.g. streams are often available at
different bitrates or using different codecs.
>>
>> Does anyone else have an interest or thoughts in this area?
>>
>> Chris
>
>It's an interesting concept and worth exploring and I see there's some
>stuff up on the wiki about it that you've started.  Might be
>worthwhile to see how much can be done with a mixture of the audio
>work, hAtom (for syndication) and hCalendar (for scheduling - time of
>air if it is time sensitive/limited broadcast)?

Syndication may be more appropriate to hAudio / hVideo as currently proposed
but I agree entirely with the latter idea for real-time streams - something
similar was proposed during the media-info discussion before it got bogged
down due to the broadness of the overall scope.

Chris

_______________________ 
Chris Newell
Lead Technologist 
BBC Research



------------------------------

Message: 6
Date: Wed, 03 Oct 2007 09:39:21 +0100
From: Chris Newell <chris.newell@rd.bbc.co.uk>
Subject: [uf-new] Internet radio and TV brainstorming
To: <microformats-new@microformats.org>
Message-ID: <6.2.0.14.2.20071002164620.02e126f0@pop3>
Content-Type: text/plain; charset="us-ascii"

I've started a brainstorming page for Internet radio and TV:
http://microformats.org/wiki/broadcast-brainstorming

Please contribute any ideas you have in this area.

Chris
_______________________ 
Chris Newell
Lead Technologist 
BBC Research



------------------------------

Message: 7
Date: Wed, 3 Oct 2007 16:28:28 +0100
From: "Frances Berriman" <fberriman@gmail.com>
Subject: [uf-new] Recipe Examples- Any more?
To: "For discussion of new microformats."
	<microformats-new@microformats.org>
Message-ID:
	<e86992a40710030828k17fe1cd1t6cb0083159f459d4@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Ben Ward has kindly tidied the recipe-brainstorm[1] page to reflect
recent discussions we've had here.

Would any other interested parties take a look please and give us any
feedback.

I think the first thing I'd like to do is query whether we feel the
examples[2] section of the work is complete enough to next discuss
commonalities and some of the proposed properties.

It does look to me like not that many, but I am feeling quite
confident that we're not going to find much more varied examples from
what's there given that our scope is to stick within food recipes
only.

Since I didn't conduct this research though, I'm keen to know other
people's feelings on it.

[1] http://microformats.org/wiki/recipe-brainstorming
[2]http://microformats.org/wiki/recipe-examples
-- 
Frances Berriman
http://fberriman.com


------------------------------

Message: 8
Date: Wed, 03 Oct 2007 19:37:51 +0100
From: "Michael Walker" <mike@yarrt.com>
Subject: [uf-new] I propose a new microformat for poems.
To: "Microformats Mailing List" <microformats-new@microformats.org>
Message-ID: <op.tzmwpdytjyd8jy@mikeslaptop>
Content-Type: text/plain; format=flowed; delsp=yes;
	charset=iso-8859-15

Well, this is my first post to this mailing list and I thought i'd start  
by addressing a problem thats been annoying me for a while.

I can't seem to find a microformat for poetry. I often write poems and  
post them to my blog (http://blog.yarrt.com), and I sometimes wonder about  
the best way to code them. Below is the method I have thought of (with one  
of my poems as an example):

[Heading Text Here, possibly a <h1>, <h2>, etc, depending on the context]
<div class="poem">
   <p class="verse">
     Standing by the roadside,<br />
     A tall dark man,<br />
     Wore a long brown coat,<br />
     Stood in the rain.
   </p>
   <p class="verse">
     Explained he had no home,<br />
     Just travelled the country,<br />
     Sleeping on the streets,<br />
     Begging for his food.
   </p>
   <p class="verse">
     "Why is he helping me?",<br />
     "Where am I going?",<br />
     He must have wondered,<br />
     While stepping into the car.
   </p>
   <p class="verse">
     He seemed uneasy,<br />
     Not sure to trust me,<br />
     He had seem too much,<br />
     To trust people blindly.
   </p>
</div>

I would suggest marking it up with the following CSS rule:
div.poem p.verse{
   margin:10px;
}

Possibly with a border around the whole poem, but that is, of course,  
completely up to you.

What do you all think?
-- 
Michael Walker, Webmaster



------------------------------

Message: 9
Date: Wed, 3 Oct 2007 11:58:11 -0700
From: "Charles Iliya Krempeaux" <supercanadian@gmail.com>
Subject: Re: [uf-new] I propose a new microformat for poems.
To: "For discussion of new microformats."
	<microformats-new@microformats.org>
Message-ID:
	<84ce626f0710031158o3896c0c2m696621437a9c7d95@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hello Michael,

On 10/3/07, Michael Walker <mike@yarrt.com> wrote:
> Well, this is my first post to this mailing list and I thought i'd start
> by addressing a problem thats been annoying me for a while.
>
> I can't seem to find a microformat for poetry. I often write poems and
> post them to my blog (http://blog.yarrt.com), and I sometimes wonder about
> the best way to code them. Below is the method I have thought of (with one
> of my poems as an example):
>

[...]

> What do you all think?

This is an excellent example of POSH.

So... you this may be a case for POSH (Plain Old Semantic HTML),
instead of a Microformat.  Here's more info on POSH...

http://microformats.org/wiki/posh


Having said that... if there are others putting poems on the web
too... then there may be a case to come up with a common POSH format
-- a Microformat.  If that's the case then you may want to look at the
Microformat process...

http://microformats.org/wiki/process


See ya




-- 
    Charles Iliya Krempeaux, B.Sc. <http://ChangeLog.ca/>


                 Vlog Razor... Vlogging News
                    http://vlograzor.com/


------------------------------

Message: 10
Date: Wed, 3 Oct 2007 13:04:34 -0600
From: Scott Reynen <scott@makedatamakesense.com>
Subject: Re: [uf-new] I propose a new microformat for poems.
To: "For discussion of new microformats."
	<microformats-new@microformats.org>
Message-ID:
	<579F2201-E9BC-4904-8B42-301DD899F5F7@makedatamakesense.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

On Oct 3, 2007, at 12:37 PM, Michael Walker wrote:

> I can't seem to find a microformat for poetry. I often write poems  
> and post them to my blog (http://blog.yarrt.com), and I sometimes  
> wonder about the best way to code them. Below is the method I have  
> thought of (with one of my poems as an example):

Before we get into brainstorming, do you have some specific use cases  
in mind for such a microformat?  What problem are we tying to solve  
here?  If you haven't already, please read about the microformats  
process:

http://microformats.org/wiki/process

--
Scott Reynen
MakeDataMakeSense.com




------------------------------

Message: 11
Date: Wed, 3 Oct 2007 18:59:46 -0300
From: "Alexandre Van de Sande" <alexandrevandesande@gmail.com>
Subject: Re: [uf-new] I propose a new microformat for poems.
To: "For discussion of new microformats."
	<microformats-new@microformats.org>
Message-ID:
	<8608a69a0710031459o271f4624lb4d75f81e25748b1@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

you mean a microformat for sonnets, or for haikus or Odes or Sestinas,
because Poetry is a broad term that defies an objective structure
needed by microformatting. And I agree with previous commenters that
this requires a problem.

On 10/3/07, Scott Reynen <scott@makedatamakesense.com> wrote:
> On Oct 3, 2007, at 12:37 PM, Michael Walker wrote:
>
> > I can't seem to find a microformat for poetry. I often write poems
> > and post them to my blog (http://blog.yarrt.com), and I sometimes
> > wonder about the best way to code them. Below is the method I have
> > thought of (with one of my poems as an example):
>
> Before we get into brainstorming, do you have some specific use cases
> in mind for such a microformat?  What problem are we tying to solve
> here?  If you haven't already, please read about the microformats
> process:
>
> http://microformats.org/wiki/process
>
> --
> Scott Reynen
> MakeDataMakeSense.com
>
>
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
>


-- 
Alexandre Van de Sande
www.wanderingabout.com
rio de janeiro

     R	



------------------------------

_______________________________________________
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new


End of microformats-new Digest, Vol 9, Issue 1
**********************************************

From andy at pigsonthewing.org.uk  Thu Oct  4 12:29:17 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Thu Oct  4 12:30:50 2007
Subject: [uf-new] Currency brainstorming
In-Reply-To: <A8lqGFrPPp$GFwo3@pigsonthewing.org.uk>
References: <615160.30567.qm@web54108.mail.re2.yahoo.com>
	<A8lqGFrPPp$GFwo3@pigsonthewing.org.uk>
Message-ID: <mkLjgSiN8TBHFwYL@pigsonthewing.org.uk>

In message <A8lqGFrPPp$GFwo3@pigsonthewing.org.uk>, Andy Mabbett
<andy@pigsonthewing.org.uk> writes

>In message <615160.30567.qm@web54108.mail.re2.yahoo.com>, Taylor Cowan
><taylor_cowan@yahoo.com> writes
>
>>Pretending to forget all that we've know up till now about
>>microformats, what if we just wanted a way for web page designers to
>>make their currency amounts unambiguous with respect to currency
>>denomination and amount?
>
>That's certainly what I want; and to be able to include dates).

I've posted a new "money" microformat straw-man on th wiki:

        <http://microformats.org/wiki/currency-brainstorming#Straw_man>

comments and suggested amendments welcome!

-- 
Andy Mabbett
From andy at pigsonthewing.org.uk  Thu Oct  4 12:30:22 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Thu Oct  4 12:32:05 2007
Subject: [uf-new] Measurement brainstorming (was: Measure & currency)
In-Reply-To: <Adq6+6txgp$GFwKO@pigsonthewing.org.uk>
References: <e86992a40709280700w3f0a110etee6409cbd74692d4@mail.gmail.com>
	<zfQWeoHa3R$GFwt8@pigsonthewing.org.uk>
	<Adq6+6txgp$GFwKO@pigsonthewing.org.uk>
Message-ID: <pU7gsqiO9TBHFw74@pigsonthewing.org.uk>

In message <Adq6+6txgp$GFwKO@pigsonthewing.org.uk>, Andy Mabbett
<andy@pigsonthewing.org.uk> writes

>Taylor Cowan's eelgant sugegstion in the Currency discussion:
>
>  <http://microformats.org/discuss/mail/microformats-new/2007-September
>/000915.html>
>
>talkes the form:
>
>        <abbr class="currency" title="USD100">one hundred bucks</abbr>
>
>abbr-accessibility issues notwithstanding, I think we can apply that to
>measurements, also

I've posted a new "measurement" microformat straw-man on th wiki:

        <http://microformats.org/wiki/measure-brainstorming#Straw_man>

comments and suggested amendments welcome!

-- 
Andy Mabbett
From julian at julianstahnke.com  Thu Oct  4 15:58:10 2007
From: julian at julianstahnke.com (Julian Stahnke)
Date: Thu Oct  4 15:58:15 2007
Subject: [uf-new] hAudio v0.7 released
In-Reply-To: <46FD1623.8000802@digitalbazaar.com>
References: <46FD1623.8000802@digitalbazaar.com>
Message-ID: <6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>

I?d like to point out that the currently proposed spec (http:// 
microformats.org/wiki/audio-info-proposal#Complete_Album_Examplet) of  
nesting an haudio element in a track element to mark up albums is  
incompatible with using tables for the track listings. In a table,  
you only have one element per track that wraps all the information  
(the table row). So both track and haudio would need to be the same  
element.

I don?t know if the current proposed mark-up is the way it is  
(nesting an haudio element inside another element ?track?) to clarify  
the relationship of the elements, or if this is actually the proposed  
solution in a strict sense. If the latter is the case, a lot of the  
sites provided as example mark-up would actually be incompatible with  
the proposed solution as they all use tables and would therefore be  
unable to nest the elements as specified. This would be unacceptable  
because I think a lot of people (as you can see, again, on the sites  
provided as examples) would agree that using a table is a valid way  
of marking up a track listing.

(Of course, one could just put another whole table with the class  
?haudio? *inside* the table row with the class ?track?, but why  
anyone would want to do this is beyond me.

On 28 Sep 2007, at 3:56pm, Manu Sporny wrote:

> An updated version of the hAudio Draft (v0.7) has been placed on the
> wiki. It contains some changes that are contested. The draft was  
> updated
> to give people a complete picture of what is currently being proposed
> for hAudio. Here are the major changes:
>
> * Added 'album'
>   (concept approved, name is disputed)
> * Added 'track'
>   (concept approved, name is disputed)
> * Changed 'audio-title' to 'recording' to bring it in line with the
>   audio type naming convention that is being proposed.
>   (concept approved, name is disputed)
> * Changed 'published-date' to 'published'
>   (concept approved, name approved)
> * Changed 'image-summary' to 'photo'
>   (concept approved, name approved)
> * Added 'podcast'
>   (concept disputed, name disputed)
> * Added 'position'
>   (concept needs analysis, name disputed)
> * Added 'description'
>   (concept needs analysis, name disputed)
>
> The schema changes are here:
>
> http://microformats.org/wiki/audio-info-proposal#Schema
>
> The disputed properties are here:
>
> http://microformats.org/wiki/audio-info-proposal#Disputed_Additions
>
> All of the examples have been updated (examples have not been provided
> for disputed properties):
>
> http://microformats.org/wiki/audio-info-proposal#Examples
>
> Feedback would be appreciated...
>
> -- manu
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new


From msporny at digitalbazaar.com  Thu Oct  4 18:09:09 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Thu Oct  4 18:09:13 2007
Subject: [uf-new] hAudio/table incompatibility (was: hAudio v0.7 released)
In-Reply-To: <6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>
References: <46FD1623.8000802@digitalbazaar.com>
	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>
Message-ID: <47058EB5.602@digitalbazaar.com>

Julian Stahnke wrote:
> I?d like to point out that the currently proposed spec
> (http://microformats.org/wiki/audio-info-proposal#Complete_Album_Examplet)
> of nesting an haudio element in a track element to mark up albums is
> incompatible with using tables for the track listings. In a table, you
> only have one element per track that wraps all the information (the
> table row). So both track and haudio would need to be the same element.

Julian, you are absolutely, 100% correct! Crap! :)

We hadn't considered the limitations of HTML tables, thanks for catching
that rather glaring problem with the new hAudio proposal.

I have a feeling that the following proposed solution is going to ruffle
a few feathers, but it seems to be the simplest way to address the
problem - make the hAudio parser do the heavy lifting.

PROPOSAL:

TRACK and HAUDIO can co-exist in the same CLASS attribute, but they must
be specified in that order. It is the hAudio parsers job to detect the
co-existence of these two properties and act accordingly.

EXAMPLE:

   <table>
    <tr><th>#</th><th>Track</th><th>Length</th></tr>
    <tr class="track haudio">
        <td>1.</td>
        <td class="recording">Sanity</td>
        <td><abbr class="duration" title="P348S">5:48</abbr></td>
    </tr>
    <tr class="track haudio">
        <td>2.</td>
        <td class="recording">Highway To Hell</td>
        <td><abbr class="duration" title="P219S">3:39</abbr></td>
    </tr>
   </table>

The only reason I mention that order is important in the attribute list
is because we might have 'track hvideo' in the future for DVD chapters,
television episodes or other track-like items.

I remember there being opposition to placing properties (TRACK) and
types (HAUDIO) together in the same CLASS attribute, but can't remember
what the logic was behind the argument.

If there is no opposition to this approach, we could adopt it and make
the parser do the hard work. Thoughts?

Below is a more complete, validated XHTML 1.0 document demonstrating the
fix. You can copy and paste it into the following URL to verify that it
is a valid XHTML 1.0 document:

http://validator.w3.org/#validate_by_input

-- manu

----------------------------------------------------------------------

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
   <title>hAudio Table Example</title>
</head>
<body>
<p>This is an example of an hAudio in a table:</p>

<div class="haudio">
   <img class="photo" alt="Live Phish Album Image"
src="images/live_phish_vol_15.jpg" />
   <p>
   <span class="album">Live Phish, Volume 15</span>
   <span class="contributor">
      <span class="vcard">
         <span class="fn org">Phish</span>
      </span>
   </span>
   </p>
   <p>
   Released on:
   <abbr class="published" title="20023110">October 31, 2002</abbr>
   </p>
   <p>
   Acquire:
   <a rel="sample" href="/samples/live_phish_vol_15_sample.mp3">Sample</a>,
   <a rel="enclosure" href="/live/phish_live_phish_vol_15.mp3">Live
Recording</a>,
   <a rel="payment" href="/buy/phish_live_phish_vol_15">Buy High Quality
Track</a>
   </p>
   <p>
   Category: <span class="category">live</span>
   </p>
   <p>
   Duration: <abbr class="duration" title="P8727S">145 minutes, 27
seconds</abbr>
   </p>
   <p>
   Price: <span class="money">
             <abbr class="currency" title="USD">$</abbr>
             <span class="amount">14.99</span>
          </span>
   </p>
   <p>
   Tracks:
   </p>
   <table>
    <tr><th>#</th><th>Track</th><th>Length</th></tr>
    <tr class="track haudio">
        <td>1.</td>
        <td class="recording">Sanity</td>
        <td><abbr class="duration" title="P348S">5:48</abbr></td>
    </tr>
    <tr class="track haudio">
        <td>2.</td>
        <td class="recording">Highway To Hell</td>
        <td><abbr class="duration" title="P219S">3:39</abbr></td>
    </tr>
   </table>
</div>

</body>
</html>

From scott at makedatamakesense.com  Thu Oct  4 18:41:56 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Thu Oct  4 18:42:00 2007
Subject: [uf-new] hAudio/table incompatibility (was: hAudio v0.7 released)
In-Reply-To: <47058EB5.602@digitalbazaar.com>
References: <46FD1623.8000802@digitalbazaar.com>
	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>
	<47058EB5.602@digitalbazaar.com>
Message-ID: <3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>

On Oct 4, 2007, at 7:09 PM, Manu Sporny wrote:

> PROPOSAL:
>
> TRACK and HAUDIO can co-exist in the same CLASS attribute, but they  
> must
> be specified in that order. It is the hAudio parsers job to detect the
> co-existence of these two properties and act accordingly.

[...]

> The only reason I mention that order is important in the attribute  
> list
> is because we might have 'track hvideo' in the future for DVD  
> chapters,
> television episodes or other track-like items.

I'm not sure l understand that reason.  If you're saying that a  
class="track haudio" should carry the same meaning as a  
class="haudio" inside a class="track", I think that's a bad idea.  It  
discards useful HTML container semantics and introduces container  
semantics to the class attribute where none have existed previously.

But I also don't understand why we were ever treating those as  
separate elements.  It seems to me we're not talking about a track  
that *contains* audio, but rather a track that *is* audio.  If that's  
the case, why wouldn't they belong in the same element?  On a similar  
topic, why does the contributor description say "The contents of the  
element must *include* a valid hCard Microformat" rather than "The  
element must *be* a valid hCard Microformat" (emphasis added)?  In  
hCalender [1] we say "ATTENDEE, CONTACT, and ORGANIZER in iCalendar  
may be represented by an hCard in hCalendar."  So we use  
class="organizer hcard" (or class="hcard organizer") because the  
organizer is exactly the same entity as the hcard.  Why should  
contributor work differently?

[1] http://microformats.org/wiki/hcalendar#More_Semantic_Equivalents

--
Scott Reynen
MakeDataMakeSense.com


From msporny at digitalbazaar.com  Thu Oct  4 20:06:35 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Thu Oct  4 20:06:38 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>
References: <46FD1623.8000802@digitalbazaar.com>	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>	<47058EB5.602@digitalbazaar.com>
	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>
Message-ID: <4705AA3B.2020802@digitalbazaar.com>

Scott Reynen wrote:
>> The only reason I mention that order is important in the attribute list
>> is because we might have 'track hvideo' in the future for DVD chapters,
>> television episodes or other track-like items.
> 
> I'm not sure l understand that reason.  If you're saying that a
> class="track haudio" should carry the same meaning as a class="haudio"
> inside a class="track", I think that's a bad idea.  It discards useful
> HTML container semantics and introduces container semantics to the class
> attribute where none have existed previously.
> 
> But I also don't understand why we were ever treating those as separate
> elements.  It seems to me we're not talking about a track that
> *contains* audio, but rather a track that *is* audio.  If that's the
> case, why wouldn't they belong in the same element?  

Yes, I agree. We are talking about a track that *is* audio. Based on
that suggestion, perhaps we can change the rules for processing TRACK to
be even more publisher-friendly.

PROPOSAL:

TRACK can be either plain text or marked up using HAUDIO.

This approach would make the following markup valid:

<div class="haudio">
...
  <span class="album">Album Title</span>
...
  <span class="track">Song Name</span>
...
</div>

the following would also be valid:

<div class="haudio">
...
   <table>
    <tr><th>#</th><th>Track</th><th>Length</th></tr>
    <tr class="track haudio">
        <td>1.</td>
        <td class="recording">Sanity</td>
        <td><abbr class="duration" title="P348S">5:48</abbr></td>
    </tr>
    <tr class="haudio track">
        <td>2.</td>
        <td class="recording">Highway To Hell</td>
        <td><abbr class="duration" title="P219S">3:39</abbr></td>
    </tr>
   </table>
...
</div>

These issues have been noted in hAudio ISSUE #11 and ISSUE #12:

http://microformats.org/wiki/audio-info-issues#Problem:_TRACK_does_not_work_in_tables

http://microformats.org/wiki/audio-info-issues#Problem:_CONTRIBUTOR_and_TRACK_are_not_publisher_friendly

> On a similar topic,
> why does the contributor description say "The contents of the element
> must *include* a valid hCard Microformat" rather than "The element must
> *be* a valid hCard Microformat" (emphasis added)?  In hCalender [1] we
> say "ATTENDEE, CONTACT, and ORGANIZER in iCalendar may be represented by
> an hCard in hCalendar."  So we use class="organizer hcard" (or
> class="hcard organizer") because the organizer is exactly the same
> entity as the hcard.  Why should contributor work differently?

It shouldn't work differently from hCalendar, and I agree again. We
should bring hAudio more in line with hCalendar. Do the following two
examples work for everybody?

This would be valid:

   <span class="contributor vcard">
         <span class="fn org">Phish</span>
   </span>

and so would this:

   <span class="contributor">Phish</span>

This has been noted in hAudio ISSUE #12:

http://microformats.org/wiki/audio-info-issues#Problem:_CONTRIBUTOR_and_TRACK_are_not_publisher_friendly

-- manu

From julian at julianstahnke.com  Fri Oct  5 01:44:26 2007
From: julian at julianstahnke.com (Julian Stahnke)
Date: Fri Oct  5 01:44:30 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <4705AA3B.2020802@digitalbazaar.com>
References: <46FD1623.8000802@digitalbazaar.com>	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>	<47058EB5.602@digitalbazaar.com>
	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>
	<4705AA3B.2020802@digitalbazaar.com>
Message-ID: <383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>

> PROPOSAL:
>
> TRACK can be either plain text or marked up using HAUDIO.
>
> This approach would make the following markup valid:
>
> <div class="haudio">
> ...
>   <span class="album">Album Title</span>
> ...
>   <span class="track">Song Name</span>
> ...
> </div>

I love this!

> It shouldn't work differently from hCalendar, and I agree again. We
> should bring hAudio more in line with hCalendar. Do the following two
> examples work for everybody?
>
> This would be valid:
>
>    <span class="contributor vcard">
>          <span class="fn org">Phish</span>
>    </span>
>
> and so would this:
>
>    <span class="contributor">Phish</span>

Again, I think this would be great. Big music sites like Last.fm  
would have no problem to implement all those nested vcard etc. in  
most cases, even though they may sometimes be a bit heavyweight.  
?Regular? people like bloggers who just want to write about music and  
mark it up accordingly would have a hard time understanding all that  
though, I think. (At least that?s my impression talking to people.)  
So this simpler proposal makes perfect sense to me.

One element per property and you just wrap the whole thing in an  
haudio element. That?s easy to explain and still covers the very  
basic information one would want to have. And if you want to have  
more details, you still can. I think that would be cool.

From chris.newell at rd.bbc.co.uk  Fri Oct  5 03:20:49 2007
From: chris.newell at rd.bbc.co.uk (Chris Newell)
Date: Fri Oct  5 03:20:53 2007
Subject: [uf-new] Measurement brainstorming (was: Measure &
  currency)
In-Reply-To: <pU7gsqiO9TBHFw74@pigsonthewing.org.uk>
References: <e86992a40709280700w3f0a110etee6409cbd74692d4@mail.gmail.com>
	<zfQWeoHa3R$GFwt8@pigsonthewing.org.uk>
	<Adq6+6txgp$GFwKO@pigsonthewing.org.uk>
	<pU7gsqiO9TBHFw74@pigsonthewing.org.uk>
Message-ID: <6.2.0.14.2.20071005101709.02e09cd8@pop3>

At 20:30 04/10/2007, you wrote:
I've posted a new "measurement" microformat straw-man on the wiki:

        <http://microformats.org/wiki/measure-brainstorming#Straw_man>

comments and suggested amendments welcome!

Andy,

I guess you may have been through this but my first thought is why not separate unit-code and value?

The reasoning being:

- Programmers hate parsing strings (particularly if you have to deal with a number of different formats and field orders) and parsing strings is notorious for causing implementation interoperability problems.

- Users may want to style the unit-code differently from the numerical value and the separation would make this easier.

- Users wouldn't have to remember rules about the format of the string.

Straw man #2 could be:

   <span class="hmeasure">
      <span class="units">[unit-code]</span>
      <span class="value">[number]</span>
   </span>

With the alternative:

   <span class="hmeasure">
      <abbr class="units" title="[unit-code]">[text]</span>
      <abbr class="value" title="[number]">[text]</span>
   </span>

The same thoughts would apply to the recent Currency strawman proposal.

Chris
_______________________ 
Chris Newell
Lead Technologist 
BBC Research

From andy at pigsonthewing.org.uk  Fri Oct  5 04:44:10 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Fri Oct  5 04:44:19 2007
Subject: [uf-new] Measurement brainstorming (was: Measure &  currency)
In-Reply-To: <6.2.0.14.2.20071005101709.02e09cd8@pop3>
References: <e86992a40709280700w3f0a110etee6409cbd74692d4@mail.gmail.com>
	<zfQWeoHa3R$GFwt8@pigsonthewing.org.uk>
	<Adq6+6txgp$GFwKO@pigsonthewing.org.uk>
	<pU7gsqiO9TBHFw74@pigsonthewing.org.uk>
	<6.2.0.14.2.20071005101709.02e09cd8@pop3>
Message-ID: <40064.80.249.57.38.1191584650.squirrel@www.gradwell.com>

On Fri, October 5, 2007 11:20, Chris Newell wrote:

>> a new "measurement" microformat straw-man on the wiki:

>> <http://microformats.org/wiki/measure-brainstorming#Straw_man>

> I guess you may have been through this but my first thought is why not
> separate unit-code and value?

Please read Taylor Cowan's original comments:

<http://microformats.org/discuss/mail/microformats-new/2007-September/000915.html>

> The reasoning being:

> - Programmers hate parsing strings (particularly if you have to deal with
> a number of different formats and field orders) and parsing strings is
> notorious for causing implementation interoperability problems.

Microformats put the burden, where possible, on parsers, not publishers,
in order to make life as easy as possible for publishers.

> - Users may want to style the unit-code differently from the numerical
> value and the separation would make this easier.

They are not prevented from doing so by the current proposal.

> - Users wouldn't have to remember rules about the format of the string.

What rules?

> Straw man #2 could be:
>
>
> <span class="hmeasure">
> <span class="units">[unit-code]</span>
> <span class="value">[number]</span>
> </span>

That's already there, as an option, under "issues".

-- 
Andy Mabbett
** via webmail **

From msporny at digitalbazaar.com  Fri Oct  5 06:52:24 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Fri Oct  5 06:53:39 2007
Subject: [uf-new] Currency brainstorming
In-Reply-To: <mkLjgSiN8TBHFwYL@pigsonthewing.org.uk>
References: <615160.30567.qm@web54108.mail.re2.yahoo.com>	<A8lqGFrPPp$GFwo3@pigsonthewing.org.uk>
	<mkLjgSiN8TBHFwYL@pigsonthewing.org.uk>
Message-ID: <47064198.4030005@digitalbazaar.com>

Andy Mabbett wrote:
> I've posted a new "money" microformat straw-man on th wiki:
> 
>         <http://microformats.org/wiki/currency-brainstorming#Straw_man>
> 
> comments and suggested amendments welcome!

Andy, I really like the new hmoney proposal. There is only one issue
that I can see:

The example uses the following markup:

<abbr class="currency" title="USD95M">$95 million</abbr>

however, the following markup possibilities are proposed:

    * [currency-code][number]
    * [currency-code][space][number]
    * [number][currency-code]
    * [number]space[currency-code]

This causes a problem with the above example when using the
[number][currency-code] markup. Take the example of Macedonian Dollars
(MKD) and the Kyat (MMK). If we wanted to mark up 50 million Macedonian
Dollars, we would do the following:

<abbr class="currency" title="95MMKD">95 million</abbr>

However, is this 95 MMK? or is it 95 million MKD? You could make the
parser a bit smarter and attempt to divine what the publisher meant, but
why are we allowing this markup in the first place?

This is one example of where too many options might confuse
publishers... can't we just use one simple markup that is easy for
publishers to understand:

[number][K|M|B|T][space][ISO-4217-currency-code]

I would also argue that we shouldn't even have K, M, B, or T - the full
number should be used.

-- manu
From chris.newell at rd.bbc.co.uk  Fri Oct  5 06:57:00 2007
From: chris.newell at rd.bbc.co.uk (Chris Newell)
Date: Fri Oct  5 06:57:05 2007
Subject: [uf-new] Measurement brainstorming (was: Measure & 
  currency)
In-Reply-To: <40064.80.249.57.38.1191584650.squirrel@www.gradwell.com>
References: <e86992a40709280700w3f0a110etee6409cbd74692d4@mail.gmail.com>
	<zfQWeoHa3R$GFwt8@pigsonthewing.org.uk>
	<Adq6+6txgp$GFwKO@pigsonthewing.org.uk>
	<pU7gsqiO9TBHFw74@pigsonthewing.org.uk>
	<6.2.0.14.2.20071005101709.02e09cd8@pop3>
	<40064.80.249.57.38.1191584650.squirrel@www.gradwell.com>
Message-ID: <6.2.0.14.2.20071005130142.02e167d8@pop3>

Andy,
At 12:44 05/10/2007, you wrote:
On Fri, October 5, 2007 11:20, Chris Newell wrote:
>>> a new "measurement" microformat straw-man on the wiki:
>>>
>>> <http://microformats.org/wiki/measure-brainstorming#Straw_man>
>>
>> I guess you may have been through this but my first thought is why not
>> separate unit-code and value?
>
>Please read Taylor Cowan's original comments:
>
><http://microformats.org/discuss/mail/microformats-new/2007-September/000915.html>
>
>> The reasoning being:
>>
>> - Programmers hate parsing strings (particularly if you have to deal with
>> a number of different formats and field orders) and parsing strings is
>> notorious for causing implementation interoperability problems.
>
>Microformats put the burden, where possible, on parsers, not publishers,
>in order to make life as easy as possible for publishers.

Agreed, but this is a balance. If it's hard to parse you'll get buggy implementations.

For "currency" the parsing is not too bad because the unit-code is restricted to ISO currency codes (a fixed set of three letter codes).

However, for "measure" (where the unit-codes encompass all SI permutations etc) parsing the string to separate the value from the unit-code gets more tricky and potentially ambiguous. For example:

   <span class="hmeasure">2m<sup>2</sup></span>

I guess this wouldn't be too bad if we can state that numbers within unit-codes are always in <sup> tags.

>> - Users may want to style the unit-code differently from the numerical
>> value and the separation would make this easier.
>
>They are not prevented from doing so by the current proposal.

I didn't say they were.

>> - Users wouldn't have to remember rules about the format of the string.
>
>What rules?

The Strawman proposal states "where parsers must accept the formats: ....."

Chris
_______________________ 
Chris Newell
Lead Technologist 
BBC Research

From andy at pigsonthewing.org.uk  Fri Oct  5 07:03:30 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Fri Oct  5 07:03:44 2007
Subject: [uf-new] Measurement brainstorming (was: Measure &   currency)
In-Reply-To: <6.2.0.14.2.20071005130142.02e167d8@pop3>
References: <e86992a40709280700w3f0a110etee6409cbd74692d4@mail.gmail.com>
	<zfQWeoHa3R$GFwt8@pigsonthewing.org.uk>
	<Adq6+6txgp$GFwKO@pigsonthewing.org.uk>
	<pU7gsqiO9TBHFw74@pigsonthewing.org.uk>
	<6.2.0.14.2.20071005101709.02e09cd8@pop3>
	<40064.80.249.57.38.1191584650.squirrel@www.gradwell.com>
	<6.2.0.14.2.20071005130142.02e167d8@pop3>
Message-ID: <42696.80.249.57.38.1191593010.squirrel@www.gradwell.com>

On Fri, October 5, 2007 14:57, Chris Newell wrote:

>> Microformats put the burden, where possible, on parsers, not
>> publishers, in order to make life as easy as possible for publishers.
>
> Agreed, but this is a balance. If it's hard to parse you'll get buggy
> implementations.

*If*; For some value of "hard to parse".

This process is about making sure that's not the case.

> for "measure" (where the unit-codes encompass all SI
> permutations etc) parsing the string to separate the value from the
> unit-code gets more tricky and potentially ambiguous. For example:
>
> <span class="hmeasure">2m<sup>2</sup></span>

That would be:

<abbr class="hmeasure" title="2m2">2m<sup>2</sup></abbr>

using "m2", or whatever is that standard for representing square-metres.

> I guess this wouldn't be too bad if we can state that numbers within
> unit-codes are always in <sup> tags.

We can't.

>>> - Users may want to style the unit-code differently from the
>>> numerical value and the separation would make this easier.
>>
>> They are not prevented from doing so by the current proposal.
>>
>
> I didn't say they were.

Then your comment appears redundant.

>>> - Users wouldn't have to remember rules about the format of the
>>> string.
>>
>> What rules?
>>
>
> The Strawman proposal states "where parsers must accept the formats:
> ....."

"parsers" not "users".

-- 
Andy Mabbett
** via webmail **

From andy at pigsonthewing.org.uk  Fri Oct  5 07:18:26 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Fri Oct  5 07:18:33 2007
Subject: [uf-new] Currency brainstorming
In-Reply-To: <47064198.4030005@digitalbazaar.com>
References: <615160.30567.qm@web54108.mail.re2.yahoo.com>	<A8lqGFrPPp$GFwo3@pigsonthewing.org.uk>
	<mkLjgSiN8TBHFwYL@pigsonthewing.org.uk>
	<47064198.4030005@digitalbazaar.com>
Message-ID: <51440.80.249.57.38.1191593906.squirrel@www.gradwell.com>

On Fri, October 5, 2007 14:52, Manu Sporny wrote:
> Andy Mabbett wrote:


>> a new "money" microformat straw-man

>> <http://microformats.org/wiki/currency-brainstorming#Straw_man>

> Andy, I really like the new hmoney proposal.

Thank you.

> There is only one issue that I can see:
>
> The example uses the following markup:

> Take the example of Macedonian Dollars
> (MKD) and the Kyat (MMK). If we wanted to mark up 50 million Macedonian
> Dollars, we would do the following:

> <abbr class="currency" title="95MMKD">95 million</abbr>

> However, is this 95 MMK? or is it 95 million MKD?

It's 95 million MKD; the last three characters must be the currency;
because "95 MMK D" isn't valid.

> You could make the
> parser a bit smarter and attempt to divine what the publisher meant, but
> why are we allowing this markup in the first place?

Because people publish amounts like "10USD" in the wild
<http://tinyurl.com/39ztv7>.

> I would also argue that we shouldn't even have K, M, B, or T - the full
> number should be used.

That's a reasonable suggestion - please add it to the "issues" section of
the above wiki page.

-- 
Andy Mabbett
** via webmail **

From chris.newell at rd.bbc.co.uk  Fri Oct  5 07:31:37 2007
From: chris.newell at rd.bbc.co.uk (Chris Newell)
Date: Fri Oct  5 07:31:44 2007
Subject: [uf-new] Measurement brainstorming (was: Measure &  
  currency)
In-Reply-To: <42696.80.249.57.38.1191593010.squirrel@www.gradwell.com>
References: <e86992a40709280700w3f0a110etee6409cbd74692d4@mail.gmail.com>
	<zfQWeoHa3R$GFwt8@pigsonthewing.org.uk>
	<Adq6+6txgp$GFwKO@pigsonthewing.org.uk>
	<pU7gsqiO9TBHFw74@pigsonthewing.org.uk>
	<6.2.0.14.2.20071005101709.02e09cd8@pop3>
	<40064.80.249.57.38.1191584650.squirrel@www.gradwell.com>
	<6.2.0.14.2.20071005130142.02e167d8@pop3>
	<42696.80.249.57.38.1191593010.squirrel@www.gradwell.com>
Message-ID: <6.2.0.14.2.20071005151318.02dfc088@pop3>

Andy,
At 15:03 05/10/2007, you wrote:
>On Fri, October 5, 2007 14:57, Chris Newell wrote:
>
>>> Microformats put the burden, where possible, on parsers, not
>>> publishers, in order to make life as easy as possible for publishers.
>>
>> Agreed, but this is a balance. If it's hard to parse you'll get buggy
>> implementations.
>
>*If*; For some value of "hard to parse".
>
>This process is about making sure that's not the case.
>
>> for "measure" (where the unit-codes encompass all SI
>> permutations etc) parsing the string to separate the value from the
>> unit-code gets more tricky and potentially ambiguous. For example:
>>
>> <span class="hmeasure">2m<sup>2</sup></span>
>
>That would be:
>
><abbr class="hmeasure" title="2m2">2m<sup>2</sup></abbr>
>
>using "m2", or whatever is that standard for representing square-metres.

Given that "parsers must accept the formats" includes [unit-code][number] would:

  <span class="hmeasure">m23</span>

represent 23 metres or 3 square-metres?

Chris

_______________________ 
Chris Newell
Lead Technologist 
BBC Research

From chris.newell at rd.bbc.co.uk  Fri Oct  5 07:38:03 2007
From: chris.newell at rd.bbc.co.uk (Chris Newell)
Date: Fri Oct  5 07:38:08 2007
Subject: [uf-new] Currency brainstorming
In-Reply-To: <47064198.4030005@digitalbazaar.com>
References: <615160.30567.qm@web54108.mail.re2.yahoo.com>
	<A8lqGFrPPp$GFwo3@pigsonthewing.org.uk>
	<mkLjgSiN8TBHFwYL@pigsonthewing.org.uk>
	<47064198.4030005@digitalbazaar.com>
Message-ID: <6.2.0.14.2.20071005153143.02df9bb8@pop3>

At 14:52 05/10/2007, you wrote:
>Andy Mabbett wrote:
>> I've posted a new "money" microformat straw-man on th wiki:
>> 
>>         <http://microformats.org/wiki/currency-brainstorming#Straw_man>
>> 
>> comments and suggested amendments welcome!
>
>Andy, I really like the new hmoney proposal. There is only one issue
>that I can see:
>
>The example uses the following markup:
>
><abbr class="currency" title="USD95M">$95 million</abbr>
>
>however, the following markup possibilities are proposed:
>
>    * [currency-code][number]
>    * [currency-code][space][number]
>    * [number][currency-code]
>    * [number]space[currency-code]
>
>This causes a problem with the above example when using the
>[number][currency-code] markup. Take the example of Macedonian Dollars
>(MKD) and the Kyat (MMK). If we wanted to mark up 50 million Macedonian
>Dollars, we would do the following:
>
><abbr class="currency" title="95MMKD">95 million</abbr>
>
>However, is this 95 MMK? or is it 95 million MKD? You could make the
>parser a bit smarter and attempt to divine what the publisher meant, but
>why are we allowing this markup in the first place?
>
>This is one example of where too many options might confuse
>publishers... can't we just use one simple markup that is easy for
>publishers to understand:
>
>[number][K|M|B|T][space][ISO-4217-currency-code]

If we applied a similar restriction to the "measure" strawman proposal e.g.

   [number][space][unit-code]

I would withdraw my concerns about the potential parsing problems.

>I would also argue that we shouldn't even have K, M, B, or T - the full
>number should be used.

Agreed.

Chris

_______________________ 
Chris Newell
Lead Technologist 
BBC Research

From andy at pigsonthewing.org.uk  Fri Oct  5 07:49:12 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Fri Oct  5 07:49:19 2007
Subject: [uf-new] Measurement brainstorming (was: Measure &    currency)
In-Reply-To: <6.2.0.14.2.20071005151318.02dfc088@pop3>
References: <e86992a40709280700w3f0a110etee6409cbd74692d4@mail.gmail.com>
	<zfQWeoHa3R$GFwt8@pigsonthewing.org.uk>
	<Adq6+6txgp$GFwKO@pigsonthewing.org.uk>
	<pU7gsqiO9TBHFw74@pigsonthewing.org.uk>
	<6.2.0.14.2.20071005101709.02e09cd8@pop3>
	<40064.80.249.57.38.1191584650.squirrel@www.gradwell.com>
	<6.2.0.14.2.20071005130142.02e167d8@pop3>
	<42696.80.249.57.38.1191593010.squirrel@www.gradwell.com>
	<6.2.0.14.2.20071005151318.02dfc088@pop3>
Message-ID: <25109.80.249.57.38.1191595752.squirrel@www.gradwell.com>

On Fri, October 5, 2007 15:31, Chris Newell wrote:

>> That would be:

>> <abbr class="hmeasure" title="2m2">2m<sup>2</sup></abbr>

>> using "m2", or whatever is that standard for representing
>> square-metres.
>
> Given that "parsers must accept the formats" includes [unit-code][number]
> would:

> <span class="hmeasure">m23</span>

> represent 23 metres or 3 square-metres?

Note that I said "or whatever is [the] standard for representing
square-metres".

-- 
Andy Mabbett
** via webmail **

From andy at pigsonthewing.org.uk  Fri Oct  5 07:50:59 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Fri Oct  5 07:51:05 2007
Subject: [uf-new] Currency brainstorming
In-Reply-To: <6.2.0.14.2.20071005153143.02df9bb8@pop3>
References: <615160.30567.qm@web54108.mail.re2.yahoo.com>
	<A8lqGFrPPp$GFwo3@pigsonthewing.org.uk>
	<mkLjgSiN8TBHFwYL@pigsonthewing.org.uk>
	<47064198.4030005@digitalbazaar.com>
	<6.2.0.14.2.20071005153143.02df9bb8@pop3>
Message-ID: <27267.80.249.57.38.1191595859.squirrel@www.gradwell.com>

On Fri, October 5, 2007 15:38, Chris Newell wrote:


> If we applied a similar restriction to the "measure" strawman proposal

There is a separate thread" for discussion of that proposal.

> e.g.
>
> [number][space][unit-code]

> I would withdraw my concerns about the potential parsing problems.

People publish measurements, without spaces, such as "4cm" in the wild.

-- 
Andy Mabbett
** via webmail **

From chris.newell at rd.bbc.co.uk  Fri Oct  5 08:18:20 2007
From: chris.newell at rd.bbc.co.uk (Chris Newell)
Date: Fri Oct  5 08:18:24 2007
Subject: [uf-new] Measurement brainstorming (was: Measure &   currency)
In-Reply-To: <25109.80.249.57.38.1191595752.squirrel@www.gradwell.com>
References: <e86992a40709280700w3f0a110etee6409cbd74692d4@mail.gmail.com>
	<zfQWeoHa3R$GFwt8@pigsonthewing.org.uk>
	<Adq6+6txgp$GFwKO@pigsonthewing.org.uk>
	<pU7gsqiO9TBHFw74@pigsonthewing.org.uk>
	<6.2.0.14.2.20071005101709.02e09cd8@pop3>
	<40064.80.249.57.38.1191584650.squirrel@www.gradwell.com>
	<6.2.0.14.2.20071005130142.02e167d8@pop3>
	<42696.80.249.57.38.1191593010.squirrel@www.gradwell.com>
	<6.2.0.14.2.20071005151318.02dfc088@pop3>
	<25109.80.249.57.38.1191595752.squirrel@www.gradwell.com>
Message-ID: <6.2.0.14.2.20071005160918.02e07d30@pop3>

Andy,
At 15:49 05/10/2007, you wrote:
>On Fri, October 5, 2007 15:31, Chris Newell wrote:
>
>>> That would be:
>
>>> <abbr class="hmeasure" title="2m2">2m<sup>2</sup></abbr>
>
>>> using "m2", or whatever is that standard for representing
>>> square-metres.
>>
>> Given that "parsers must accept the formats" includes [unit-code][number]
>> would:
>
>> <span class="hmeasure">m23</span>
>
>> represent 23 metres or 3 square-metres?
>
>Note that I said "or whatever is [the] standard for representing
>square-metres".

I'm not sure there is a standard for representing the superscripts used within SI units using plain text.

We may have to specify something.

Chris

_______________________ 
Chris Newell
Lead Technologist 
BBC Research

From msporny at digitalbazaar.com  Fri Oct  5 08:47:09 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Fri Oct  5 08:48:25 2007
Subject: [uf-new] Measurement brainstorming
In-Reply-To: <6.2.0.14.2.20071005160918.02e07d30@pop3>
References: <e86992a40709280700w3f0a110etee6409cbd74692d4@mail.gmail.com>	<zfQWeoHa3R$GFwt8@pigsonthewing.org.uk>	<Adq6+6txgp$GFwKO@pigsonthewing.org.uk>	<pU7gsqiO9TBHFw74@pigsonthewing.org.uk>	<6.2.0.14.2.20071005101709.02e09cd8@pop3>	<40064.80.249.57.38.1191584650.squirrel@www.gradwell.com>	<6.2.0.14.2.20071005130142.02e167d8@pop3>	<42696.80.249.57.38.1191593010.squirrel@www.gradwell.com>	<6.2.0.14.2.20071005151318.02dfc088@pop3>	<25109.80.249.57.38.1191595752.squirrel@www.gradwell.com>
	<6.2.0.14.2.20071005160918.02e07d30@pop3>
Message-ID: <47065C7D.9090303@digitalbazaar.com>

Chris Newell wrote:
>> Note that I said "or whatever is [the] standard for representing
>> square-metres".
> 
> I'm not sure there is a standard for representing the superscripts 
> used within SI units using plain text.
> 
> We may have to specify something.

These are all good discussions, but I'm afraid that the second we get
into "We might have to specify something", we're going to get into
philosophical debates about how we represent prefixes, units and the
combinations thereof... thereby killing the discussion :)

In an attempt to avoid those philosophical debates, let's build on the
work of great people. Namely, the ISO and SI standards of measurement
used by the international community. I have put up Straw Man 2 on the
wiki in an attempt to outline basic markup that hmeasure could support:

http://microformats.org/wiki/measure-brainstorming#Straw_man_2

The Strawman includes the following new concepts:

- The proposal only uses abbr to avoid the "but the parsers are going to
  be so complicated!" argument. Let's focus on what we can represent
  using <abbr> - what we can support in <span> will naturally come out
  of that discussion.
- This is a first cut and is missing things like measurements for
  "cups", "feet", etc.
- SI-prefixes should be used when applicable.
- It attempts to simplify and focus the discussion on <abbr>

-- manu
From chris.newell at rd.bbc.co.uk  Fri Oct  5 09:28:21 2007
From: chris.newell at rd.bbc.co.uk (Chris Newell)
Date: Fri Oct  5 09:28:26 2007
Subject: [uf-new] Measurement brainstorming
In-Reply-To: <47065C7D.9090303@digitalbazaar.com>
References: <e86992a40709280700w3f0a110etee6409cbd74692d4@mail.gmail.com>
	<zfQWeoHa3R$GFwt8@pigsonthewing.org.uk>
	<Adq6+6txgp$GFwKO@pigsonthewing.org.uk>
	<pU7gsqiO9TBHFw74@pigsonthewing.org.uk>
	<6.2.0.14.2.20071005101709.02e09cd8@pop3>
	<40064.80.249.57.38.1191584650.squirrel@www.gradwell.com>
	<6.2.0.14.2.20071005130142.02e167d8@pop3>
	<42696.80.249.57.38.1191593010.squirrel@www.gradwell.com>
	<6.2.0.14.2.20071005151318.02dfc088@pop3>
	<25109.80.249.57.38.1191595752.squirrel@www.gradwell.com>
	<6.2.0.14.2.20071005160918.02e07d30@pop3>
	<47065C7D.9090303@digitalbazaar.com>
Message-ID: <6.2.0.14.2.20071005170303.02e2bbf0@pop3>

Andy,
At 16:47 05/10/2007, you wrote:
>I have put up Straw Man 2 on the
>wiki in an attempt to outline basic markup that hmeasure could support:
>
>http://microformats.org/wiki/measure-brainstorming#Straw_man_2
>
>The Strawman includes the following new concepts:
>
>- The proposal only uses abbr to avoid the "but the parsers are going to
>  be so complicated!" argument. Let's focus on what we can represent
>  using <abbr> - what we can support in <span> will naturally come out
>  of that discussion.
>- This is a first cut and is missing things like measurements for
>  "cups", "feet", etc.
>- SI-prefixes should be used when applicable.
>- It attempts to simplify and focus the discussion on <abbr>

Looks good.

We could also reference http://en.wikipedia.org/wiki/SI_derived_unit and http://en.wikipedia.org/wiki/Non-SI_units_accepted_for_use_with_SI which expand the number of units in a controlled way.

Even so, these references don't provide a suitable unit for bit-rate so I'd like to add "bit" as a supported unit, for use with the other entities you've defined e.g. "kbit/s".

Chris

_______________________ 
Chris Newell
Lead Technologist 
BBC Research

From martin at weborganics.co.uk  Fri Oct  5 10:31:37 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Fri Oct  5 10:31:01 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>
References: <46FD1623.8000802@digitalbazaar.com>
	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>
	<47058EB5.602@digitalbazaar.com>
	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>
	<4705AA3B.2020802@digitalbazaar.com>
	<383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>
Message-ID: <1191605497.31012.6.camel@localhost.localdomain>

On Fri, 2007-10-05 at 09:44 +0100, Julian Stahnke wrote:
> > PROPOSAL:
> >
> > TRACK can be either plain text or marked up using HAUDIO.
> >
> > This approach would make the following markup valid:
> >
> > <div class="haudio">
> > ...
> >   <span class="album">Album Title</span>
> > ...
> >   <span class="track">Song Name</span>
> > ...
> > </div>
> 
> I love this!

[ ... ]


> 
> > It shouldn't work differently from hCalendar, and I agree again. We
> > should bring hAudio more in line with hCalendar. Do the following two
> > examples work for everybody?
> >
> > This would be valid:
> >
> >    <span class="contributor vcard">
> >          <span class="fn org">Phish</span>
> >    </span>
> >
> > and so would this:
> >
> >    <span class="contributor">Phish</span>
> 
> Again, I think this would be great. Big music sites like Last.fm  
> would have no problem to implement all those nested vcard etc. in  
> most cases, even though they may sometimes be a bit heavyweight.  
> ?Regular? people like bloggers who just want to write about music and  
> mark it up accordingly would have a hard time understanding all that  
> though, I think. (At least that?s my impression talking to people.)  
> So this simpler proposal makes perfect sense to me.

Thank you for your comments Julian at least someone on the list Is
starting to make sense.

I have been wrestling with the current proposal of hAudio since Manu
made his announcement [1] And frankly the current proposal is starting
to make less and less sense to me,  With each different proposal the
concept of hAudio gets more and more vague. and honestly I dont like it
at all the way hAudio stands now.

What happened to keep it Simple,  and *Meaningful*?

So let Keep it simple eh?

PROPOSAL:

<div class="haudio">
   <span class="audio-title">Album Title</span>
   <span class="contributor vcard">[...]Artist[...]</span>
   <div class="track">1
        <span class="track-title">Track One</span>
        [...]
    </div>
    <div class="track">2
         <span class="track-title">Track Two</span>
       [...]
    </div>
</div>

Notice no need to Reiterate hAudio over and over again, hAudio only=20
needs to be declared *ONCE* because the entire contents *ARE* hAudio

Does hAudio really need to be more involved than the above example?

I feel the more we bloat hAudio with *not* well thought of semantic
class names such as *Album* (a container class or object not a title)
and *Podcast* (which is also a container class and not a title) the
less 

Publishers are going to use hAudio because it makes it difficult to
understand and integrate with their webpages.

> 
> One element per property and you just wrap the whole thing in an  
> haudio element. That?s easy to explain and still covers the very  
> basic information one would want to have. And if you want to have  
> more details, you still can. I think that would be cool.

[...]

Thanks

Martin McEvoy
[1]
http://microformats.org/discuss/mail/microformats-new/2007-September/000885.html
> 
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From msporny at digitalbazaar.com  Fri Oct  5 11:34:00 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Fri Oct  5 11:35:19 2007
Subject: [uf-new] Measurement brainstorming
In-Reply-To: <6.2.0.14.2.20071005170303.02e2bbf0@pop3>
References: <e86992a40709280700w3f0a110etee6409cbd74692d4@mail.gmail.com>	<zfQWeoHa3R$GFwt8@pigsonthewing.org.uk>	<Adq6+6txgp$GFwKO@pigsonthewing.org.uk>	<pU7gsqiO9TBHFw74@pigsonthewing.org.uk>	<6.2.0.14.2.20071005101709.02e09cd8@pop3>	<40064.80.249.57.38.1191584650.squirrel@www.gradwell.com>	<6.2.0.14.2.20071005130142.02e167d8@pop3>	<42696.80.249.57.38.1191593010.squirrel@www.gradwell.com>	<6.2.0.14.2.20071005151318.02dfc088@pop3>	<25109.80.249.57.38.1191595752.squirrel@www.gradwell.com>	<6.2.0.14.2.20071005160918.02e07d30@pop3>	<47065C7D.9090303@digitalbazaar.com>
	<6.2.0.14.2.20071005170303.02e2bbf0@pop3>
Message-ID: <47068398.4010805@digitalbazaar.com>

Chris Newell wrote:
>> The Strawman includes the following new concepts:
>>
>> - The proposal only uses abbr to avoid the "but the parsers are going to
>>  be so complicated!" argument. Let's focus on what we can represent
>>  using <abbr> - what we can support in <span> will naturally come out
>>  of that discussion.
>> - This is a first cut and is missing things like measurements for
>>  "cups", "feet", etc.
>> - SI-prefixes should be used when applicable.
>> - It attempts to simplify and focus the discussion on <abbr>
> 
> Looks good.

Chris, just to clarify - those were my suggestions, not Andy's. I don't
know if Andy agrees with this approach or not. If he does, then that's
great... but I don't want to put any words into his mouth. :)

> We could also reference http://en.wikipedia.org/wiki/SI_derived_unit and 
> http://en.wikipedia.org/wiki/Non-SI_units_accepted_for_use_with_SI
> which expand the number of units in a controlled way.

I have included the SI derived units and the Non-SI accepted units.

> Even so, these references don't provide a suitable unit for bit-rate 
> so I'd like to add "bit" as a supported unit, for use with the other
> entities you've defined e.g. "kbit/s".

I have also added 'bit' under "Units Defined by Microformats.org".

Changes can be found here:

http://microformats.org/wiki/measure-brainstorming#Supported_Derived_SI_Units

http://microformats.org/wiki/measure-brainstorming#Supported_Non-SI_Units

http://microformats.org/wiki/measure-brainstorming#Units_Defined_by_Microformats.org

-- manu

From msporny at digitalbazaar.com  Fri Oct  5 13:08:45 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Fri Oct  5 13:10:06 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <1191605497.31012.6.camel@localhost.localdomain>
References: <46FD1623.8000802@digitalbazaar.com>	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>	<47058EB5.602@digitalbazaar.com>	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>	<4705AA3B.2020802@digitalbazaar.com>	<383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>
	<1191605497.31012.6.camel@localhost.localdomain>
Message-ID: <470699CD.3050001@digitalbazaar.com>

Martin McEvoy wrote:
> On Fri, 2007-10-05 at 09:44 +0100, Julian Stahnke wrote:
>> So this simpler proposal makes perfect sense to me.
> 
> at least someone on the list Is starting to make sense.

Criticize the ideas, not the people, please. :)

> I have been wrestling with the current proposal of hAudio since Manu
> made his announcement [1] And frankly the current proposal is starting
> to make less and less sense to me,  With each different proposal the
> concept of hAudio gets more and more vague. and honestly I dont like it
> at all the way hAudio stands now.
> 
> What happened to keep it Simple, and *Meaningful*?

We are attempting to keep it simple... remember, if we don't have ALBUM
and TRACK - we have to have the hAlbum Microformat. hAlbum is an order
of magnitude more complicated than what is currently being proposed.

What part of the mark-up isn't "meaningful" to you? Please be very
explicit as I'm having a hard time following what part of the hAudio
specification you don't like. Preface your statements with "This
concerns hAudio ISSUE #N..."

> So let Keep it simple eh?
> 
> PROPOSAL:
> 
> <div class="haudio">
>    <span class="audio-title">Album Title</span>
>    <span class="contributor vcard">[...]Artist[...]</span>
>    <div class="track">1
>         <span class="track-title">Track One</span>
>         [...]
>     </div>
>     <div class="track">2
>          <span class="track-title">Track Two</span>
>        [...]
>     </div>
> </div>
> 
> Notice no need to Reiterate hAudio over and over again, hAudio only=20
> needs to be declared *ONCE* because the entire contents *ARE* hAudio

Please take a bit more time to outline your objection more clearly.
Which one of the hAudio ISSUES is this about?

http://microformats.org/wiki/audio-info-issues#Problem:_TRACK_does_not_work_in_tables

I'm guessing that you don't like the fact that you must define both
TRACK and HAUDIO?

The reason that we're doing this is because we might want to re-use
TRACK (or whatever we end up calling it) in hVideo.

Content has sections:

Albums have Tracks
Television Series have Episodes
DVDs have Chapters
Books have Chapters

We could end up re-using TRACK to describe DVDs like so:

<div class="hvideo">
...
   <span class="dvd">The Matrix</span>
...
   <span class="track hvideo">Chapter 27: The Lobby</span>
...
   <span class="track haudio">Chinese Audio Track</span>
...
</div>

If we don't specify hvideo for the video track and haudio for the audio
track, how would the parser determine the difference? We would have
ambiguity, which is one of the reasons all of the other Microformats do
this as well.

If you want to push your proposal above, you will have to make the
following arguments:

1. Why Ambiguity is not an issue for TRACK.
2. Why we should introduce a new property called TRACK-TITLE.
3. Why we should require CONTRIBUTOR to be marked up via a VCARD.

> I feel the more we bloat hAudio with *not* well thought of semantic
> class names such as *Album* (a container class or object not a title)

ALBUM is not a container class, it defines two things:

- the name of an audio album
- the type of the hAudio

The examples require us to have something like this, so is your
opposition to it's name... or the concept that we need something to
denote the name and type of an hAudio?

> and *Podcast* (which is also a container class and not a title) the
> less 

PODCAST will probably not make it in unless somebody other than me
starts supporting it.

Let me point out that we have plenty of podcast examples:

http://microformats.org/wiki/audio-info-examples#Music_Podcasting

I'd like hAudio to be completed sooner than later and if PODCAST is
going to cause push-back, then I'd much rather drop it and move on...
even though we have a number of examples to support putting podcast in
hAudio.

-- manu

From martin at weborganics.co.uk  Sat Oct  6 03:49:43 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sat Oct  6 03:49:07 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <470699CD.3050001@digitalbazaar.com>
References: <46FD1623.8000802@digitalbazaar.com>
	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>
	<47058EB5.602@digitalbazaar.com>
	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>
	<4705AA3B.2020802@digitalbazaar.com>
	<383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>
	<1191605497.31012.6.camel@localhost.localdomain>
	<470699CD.3050001@digitalbazaar.com>
Message-ID: <1191667783.5782.45.camel@localhost.localdomain>

On Fri, 2007-10-05 at 16:08 -0400, Manu Sporny wrote:
> Martin McEvoy wrote:
> > On Fri, 2007-10-05 at 09:44 +0100, Julian Stahnke wrote:
> >> So this simpler proposal makes perfect sense to me.
> > 
> > at least someone on the list Is starting to make sense.
> 
> Criticize the ideas, not the people, please. :)
> 
> > I have been wrestling with the current proposal of hAudio since Manu
> > made his announcement [1] And frankly the current proposal is starting
> > to make less and less sense to me,  With each different proposal the
> > concept of hAudio gets more and more vague. and honestly I dont like it
> > at all the way hAudio stands now.
> > 
> > What happened to keep it Simple, and *Meaningful*?
> 
> We are attempting to keep it simple... remember, if we don't have ALBUM
> and TRACK - we have to have the hAlbum Microformat. hAlbum is an order
> of magnitude more complicated than what is currently being proposed.
> 
> What part of the mark-up isn't "meaningful" to you? Please be very
> explicit as I'm having a hard time following what part of the hAudio
> specification you don't like. Preface your statements with "This
> concerns hAudio ISSUE #N..."
> 
> > So let Keep it simple eh?
> > 
> > PROPOSAL:
> > 
> > <div class="haudio">
> >    <span class="audio-title">Album Title</span>
> >    <span class="contributor vcard">[...]Artist[...]</span>
> >    <div class="track">1
> >         <span class="track-title">Track One</span>
> >         [...]
> >     </div>
> >     <div class="track">2
> >          <span class="track-title">Track Two</span>
> >        [...]
> >     </div>
> > </div>
> > 
> > Notice no need to Reiterate hAudio over and over again, hAudio only=20
> > needs to be declared *ONCE* because the entire contents *ARE* hAudio
> 
> Please take a bit more time to outline your objection more clearly.
> Which one of the hAudio ISSUES is this about?

all the general hAudio proposal....

> 
> http://microformats.org/wiki/audio-info-issues#Problem:_TRACK_does_not_work_in_tables
> 
> I'm guessing that you don't like the fact that you must define both
> TRACK and HAUDIO?
> 
> The reason that we're doing this is because we might want to re-use
> TRACK (or whatever we end up calling it) in hVideo.
> 
> Content has sections:
> 
> Albums have Tracks
> Television Series have Episodes
> DVDs have Chapters
> Books have Chapters
> 
> We could end up re-using TRACK to describe DVDs like so:
> 
> <div class="hvideo">
> ...
>    <span class="dvd">The Matrix</span>
> ...
>    <span class="track hvideo">Chapter 27: The Lobby</span>
> ...
>    <span class="track haudio">Chinese Audio Track</span>
> ...
> </div>

[?]

> 
> If we don't specify hvideo for the video track and haudio for the audio
> track, how would the parser determine the difference? We would have
> ambiguity, which is one of the reasons all of the other Microformats do
> this as well.
> 
> If you want to push your proposal above, you will have to make the
> following arguments:
> 
> 1. Why Ambiguity is not an issue for TRACK.

It is an ambiguity when you couple it with another instance of hAudio 
, it shouldn't I cause such confusions I don't think. TRACK should be
clearly defined as a child element of hAudio for it to contain hAudio
seems confusing an unnecessary:

haudio 
  track
    haudio

? 
hAudio inside hAudio ?...  

> 2. Why we should introduce a new property called TRACK-TITLE.

You Have proposed 

recording, album, track, podcast,  position and  description

5 new properties ONE reused from hAlbum *Track* the rest !!! 

You decided from the Issues page I Hope?

http://microformats.org/wiki/audio-info-issues

First I notice that you have dropped the audio-title property?

http://microformats.org/wiki/audio-info-issues#audio-title_Property

Only YOU made a vote for changing the current propsal which clearly
means to me that only you had an issue with this?
 +1 : use RECORDING and ALBUM ManuSporny 18:20, 27 Sep 2007 (PDT)

My Proposal Suggests We Keep it I voted Against changing it 
-1 : don't change audio-title Martin McEvoy 15:48, 14 Aug 2007 (GMT)

David Janes voted also on this issue
+1 for using FN, no clear difference between two so why invent another
David Janes 14 August 2007

I would take that as a vote against or changing it entirely

My view would be from the *Three* votes we had that this was really a
*NON ISSUE* but you changed it any way to reflect your views?
 
> 3. Why we should require CONTRIBUTOR to be marked up via a VCARD.

It Doesn't Just a recomendation as per the hAudio Spec.

>   
> > I feel the more we bloat hAudio with *not* well thought of semantic
> > class names such as *Album* (a container class or object not a title)
> 
> ALBUM is not a container class, 

In your view It Isn't..

In my View IT IS
You re used the already discovered meaning of hAlbum I Presume?

http://microformats.org/wiki/audio-album-proposal#hAlbum
http://microformats.org/wiki/audio-album-proposal#Simple_Album_Example


> it defines two things:
> 
> - the name of an audio album
> - the type of the hAudio
> 
> The examples require us to have something like this, so is your
> opposition to it's name... or the concept that we need something to
> denote the name and type of an hAudio?
> 
> > and *Podcast* (which is also a container class and not a title) the
> > less 
> 
> PODCAST will probably not make it in unless somebody other than me
> starts supporting it.
> 
> Let me point out that we have plenty of podcast examples:
> 
> http://microformats.org/wiki/audio-info-examples#Music_Podcasting
> 
> I'd like hAudio to be completed sooner than later and if PODCAST is
> going to cause push-back, then I'd much rather drop it and move on...
> even though we have a number of examples to support putting podcast in
> hAudio.

I propose You change the hAudio Proposal back to the 0.6 version UNTILL
these ISSUES have been resolved YOU cant Just change the proposal to
reflect your personal views..

Manu you didnt even notify the list that you were making these changes
untill AFTER the changes were made.

Frankly I resent the way you are seeming to bully this community into
fiting into hAudio RDFa agenda 

http://wiki.digitalbazaar.com/en/HAudio_RDFa

which you have said yourself is more useful than the Microformat
Proposal

http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Oct/0017.html

Thanks

Martin
> 
> -- manu
> 
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From martin at weborganics.co.uk  Sat Oct  6 04:31:12 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sat Oct  6 04:30:35 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <1191667783.5782.45.camel@localhost.localdomain>
References: <46FD1623.8000802@digitalbazaar.com>
	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>
	<47058EB5.602@digitalbazaar.com>
	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>
	<4705AA3B.2020802@digitalbazaar.com>
	<383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>
	<1191605497.31012.6.camel@localhost.localdomain>
	<470699CD.3050001@digitalbazaar.com>
	<1191667783.5782.45.camel@localhost.localdomain>
Message-ID: <1191670272.5782.48.camel@localhost.localdomain>

On Sat, 2007-10-06 at 11:49 +0100, Martin McEvoy wrote:
> On Fri, 2007-10-05 at 16:08 -0400, Manu Sporny wrote:
> > Martin McEvoy wrote:
> > > On Fri, 2007-10-05 at 09:44 +0100, Julian Stahnke wrote:
> > >> So this simpler proposal makes perfect sense to me.
> > > 
> > > at least someone on the list Is starting to make sense.

Oh And thanks for Quoting me out of context..

http://microformats.org/discuss/mail/microformats-new/2007-October/000958.html

> > 
> > Criticize the ideas, not the people, please. :)
> > 
> > > I have been wrestling with the current proposal of hAudio since Manu
> > > made his announcement [1] And frankly the current proposal is starting
> > > to make less and less sense to me,  With each different proposal the
> > > concept of hAudio gets more and more vague. and honestly I dont like it
> > > at all the way hAudio stands now.
> > > 
> > > What happened to keep it Simple, and *Meaningful*?
> > 
> > We are attempting to keep it simple... remember, if we don't have ALBUM
> > and TRACK - we have to have the hAlbum Microformat. hAlbum is an order
> > of magnitude more complicated than what is currently being proposed.
> > 
> > What part of the mark-up isn't "meaningful" to you? Please be very
> > explicit as I'm having a hard time following what part of the hAudio
> > specification you don't like. Preface your statements with "This
> > concerns hAudio ISSUE #N..."
> > 
> > > So let Keep it simple eh?
> > > 
> > > PROPOSAL:
> > > 
> > > <div class="haudio">
> > >    <span class="audio-title">Album Title</span>
> > >    <span class="contributor vcard">[...]Artist[...]</span>
> > >    <div class="track">1
> > >         <span class="track-title">Track One</span>
> > >         [...]
> > >     </div>
> > >     <div class="track">2
> > >          <span class="track-title">Track Two</span>
> > >        [...]
> > >     </div>
> > > </div>
> > > 
> > > Notice no need to Reiterate hAudio over and over again, hAudio only=20
> > > needs to be declared *ONCE* because the entire contents *ARE* hAudio
> > 
> > Please take a bit more time to outline your objection more clearly.
> > Which one of the hAudio ISSUES is this about?
> 
> all the general hAudio proposal....
> 
> > 
> > http://microformats.org/wiki/audio-info-issues#Problem:_TRACK_does_not_work_in_tables
> > 
> > I'm guessing that you don't like the fact that you must define both
> > TRACK and HAUDIO?
> > 
> > The reason that we're doing this is because we might want to re-use
> > TRACK (or whatever we end up calling it) in hVideo.
> > 
> > Content has sections:
> > 
> > Albums have Tracks
> > Television Series have Episodes
> > DVDs have Chapters
> > Books have Chapters
> > 
> > We could end up re-using TRACK to describe DVDs like so:
> > 
> > <div class="hvideo">
> > ...
> >    <span class="dvd">The Matrix</span>
> > ...
> >    <span class="track hvideo">Chapter 27: The Lobby</span>
> > ...
> >    <span class="track haudio">Chinese Audio Track</span>
> > ...
> > </div>
> 
> [?]
> 
> > 
> > If we don't specify hvideo for the video track and haudio for the audio
> > track, how would the parser determine the difference? We would have
> > ambiguity, which is one of the reasons all of the other Microformats do
> > this as well.
> > 
> > If you want to push your proposal above, you will have to make the
> > following arguments:
> > 
> > 1. Why Ambiguity is not an issue for TRACK.
> 
> It is an ambiguity when you couple it with another instance of hAudio 
> , it shouldn't I cause such confusions I don't think. TRACK should be
> clearly defined as a child element of hAudio for it to contain hAudio
> seems confusing an unnecessary:
> 
> haudio 
>   track
>     haudio
> 
> ? 
> hAudio inside hAudio ?...  
> 
> > 2. Why we should introduce a new property called TRACK-TITLE.
> 
> You Have proposed 
> 
> recording, album, track, podcast,  position and  description
> 
> 5 new properties ONE reused from hAlbum *Track* the rest !!! 
> 
> You decided from the Issues page I Hope?
> 
> http://microformats.org/wiki/audio-info-issues
> 
> First I notice that you have dropped the audio-title property?
> 
> http://microformats.org/wiki/audio-info-issues#audio-title_Property
> 
> Only YOU made a vote for changing the current propsal which clearly
> means to me that only you had an issue with this?
>  +1 : use RECORDING and ALBUM ManuSporny 18:20, 27 Sep 2007 (PDT)
> 
> My Proposal Suggests We Keep it I voted Against changing it 
> -1 : don't change audio-title Martin McEvoy 15:48, 14 Aug 2007 (GMT)
> 
> David Janes voted also on this issue
> +1 for using FN, no clear difference between two so why invent another
> David Janes 14 August 2007
> 
> I would take that as a vote against or changing it entirely
> 
> My view would be from the *Three* votes we had that this was really a
> *NON ISSUE* but you changed it any way to reflect your views?
>  
> > 3. Why we should require CONTRIBUTOR to be marked up via a VCARD.
> 
> It Doesn't Just a recomendation as per the hAudio Spec.
> 
> >   
> > > I feel the more we bloat hAudio with *not* well thought of semantic
> > > class names such as *Album* (a container class or object not a title)
> > 
> > ALBUM is not a container class, 
> 
> In your view It Isn't..
> 
> In my View IT IS
> You re used the already discovered meaning of hAlbum I Presume?
> 
> http://microformats.org/wiki/audio-album-proposal#hAlbum
> http://microformats.org/wiki/audio-album-proposal#Simple_Album_Example
> 
> 
> > it defines two things:
> > 
> > - the name of an audio album
> > - the type of the hAudio
> > 
> > The examples require us to have something like this, so is your
> > opposition to it's name... or the concept that we need something to
> > denote the name and type of an hAudio?
> > 
> > > and *Podcast* (which is also a container class and not a title) the
> > > less 
> > 
> > PODCAST will probably not make it in unless somebody other than me
> > starts supporting it.
> > 
> > Let me point out that we have plenty of podcast examples:
> > 
> > http://microformats.org/wiki/audio-info-examples#Music_Podcasting
> > 
> > I'd like hAudio to be completed sooner than later and if PODCAST is
> > going to cause push-back, then I'd much rather drop it and move on...
> > even though we have a number of examples to support putting podcast in
> > hAudio.
> 
> I propose You change the hAudio Proposal back to the 0.6 version UNTILL
> these ISSUES have been resolved YOU cant Just change the proposal to
> reflect your personal views..
> 
> Manu you didnt even notify the list that you were making these changes
> untill AFTER the changes were made.
> 
> Frankly I resent the way you are seeming to bully this community into
> fiting into hAudio RDFa agenda 
> 
> http://wiki.digitalbazaar.com/en/HAudio_RDFa
> 
> which you have said yourself is more useful than the Microformat
> Proposal
> 
> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Oct/0017.html
> 
> Thanks
> 
> Martin
> > 
> > -- manu
> > 
> > _______________________________________________
> > microformats-new mailing list
> > microformats-new@microformats.org
> > http://microformats.org/mailman/listinfo/microformats-new

From scott at makedatamakesense.com  Sat Oct  6 07:53:06 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Sat Oct  6 07:53:10 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <1191670272.5782.48.camel@localhost.localdomain>
References: <46FD1623.8000802@digitalbazaar.com>
	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>
	<47058EB5.602@digitalbazaar.com>
	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>
	<4705AA3B.2020802@digitalbazaar.com>
	<383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>
	<1191605497.31012.6.camel@localhost.localdomain>
	<470699CD.3050001@digitalbazaar.com>
	<1191667783.5782.45.camel@localhost.localdomain>
	<1191670272.5782.48.camel@localhost.localdomain>
Message-ID: <18A82A57-257A-4C92-B562-4C539D1759B5@makedatamakesense.com>

>>> So this simpler proposal makes perfect sense to me.
>>
>> at least someone on the list Is starting to make sense.
>
> Oh And thanks for Quoting me out of context..

Let's all try to clearly state what we mean without sarcasm and  
avoiding assumptions about what others mean, in the interest of  
clarifying disagreement and finding agreement.

--
Scott Reynen
MakeDataMakeSense.com


From julian at julianstahnke.com  Sat Oct  6 11:24:26 2007
From: julian at julianstahnke.com (Julian Stahnke)
Date: Sat Oct  6 11:24:31 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <470699CD.3050001@digitalbazaar.com>
References: <46FD1623.8000802@digitalbazaar.com>	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>	<47058EB5.602@digitalbazaar.com>	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>	<4705AA3B.2020802@digitalbazaar.com>	<383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>
	<1191605497.31012.6.camel@localhost.localdomain>
	<470699CD.3050001@digitalbazaar.com>
Message-ID: <85137B17-28D2-4A07-87E7-7864A39EDAEA@julianstahnke.com>

> I'm guessing that you don't like the fact that you must define both
> TRACK and HAUDIO?
>
> The reason that we're doing this is because we might want to re-use
> TRACK (or whatever we end up calling it) in hVideo.
>
> Content has sections:
>
> Albums have Tracks
> Television Series have Episodes
> DVDs have Chapters
> Books have Chapters
>
> We could end up re-using TRACK to describe DVDs like so:
>
> <div class="hvideo">
> ...
>    <span class="dvd">The Matrix</span>
> ...
>    <span class="track hvideo">Chapter 27: The Lobby</span>
> ...
>    <span class="track haudio">Chinese Audio Track</span>
> ...
> </div>
>
> If we don't specify hvideo for the video track and haudio for the  
> audio
> track, how would the parser determine the difference? We would have
> ambiguity, which is one of the reasons all of the other  
> Microformats do
> this as well.
>
> If you want to push your proposal above, you will have to make the
> following arguments:
>
> 1. Why Ambiguity is not an issue for TRACK.
> 2. Why we should introduce a new property called TRACK-TITLE.
> 3. Why we should require CONTRIBUTOR to be marked up via a VCARD.

About tracks inside hAudio/hVideo: What about assuming that the track  
has the same media type as its parent element unless declared otherwise?

That way, the following?mentioned before?would thus be possible:

<div class="haudio">
...
   <span class="album">Album Title</span>
...
   <span class="track">Song Name</span>
...
</div>

What does ?track? mean in the context of the hVideo format, though? I  
would assume, from my limited forays into the world of video editing  
and from DVDs I own, that there can be multiple audio tracks that run  
in parallel. You can then choose one (?English?, for example) or even  
two which then run in parallel (?English? and ?Director?s comments?  
on a DVD).

The usage of ?track? specifically in hAudio (and rightfully so) is a  
sequential one, though. One track comes after another. So while it  
shares the same name, it?s (to my mind) an entirely different concept  
than a track found on a CD.

I?m not saying that one shouldn?t use the name track for hVideo?by no  
means, it seems to be quite valid. But I think it?s dangerous to  
define ?track? _across_ the boundaries of it?s definition in the  
container it?s used in. Maybe it should not have a definition by its  
own but only in context with the microformat it is used in. (Same as,  
for example, ?boot??it can either be something you wear on your foot  
or a part of a car.)

Then again, that might be quite confusing. I?m very confused already,  
for you could also map ?track? in hVideo to what commonly is referred  
to as a ?chapter? on a DVD. Which would be against its common usage  
in everyday language (I think). Maybe I missed a bit that would shed  
some light on this, but I think this issue needs some clarification.

For the record: I?m totally for using ?track? in hAudio, I?m just  
wary of trying to define it in a way that makes it be exactly the  
same in hVideo as well.

From julian at julianstahnke.com  Sat Oct  6 11:36:46 2007
From: julian at julianstahnke.com (Julian Stahnke)
Date: Sat Oct  6 11:37:24 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <85137B17-28D2-4A07-87E7-7864A39EDAEA@julianstahnke.com>
References: <46FD1623.8000802@digitalbazaar.com>	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>	<47058EB5.602@digitalbazaar.com>	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>	<4705AA3B.2020802@digitalbazaar.com>	<383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>
	<1191605497.31012.6.camel@localhost.localdomain>
	<470699CD.3050001@digitalbazaar.com>
	<85137B17-28D2-4A07-87E7-7864A39EDAEA@julianstahnke.com>
Message-ID: <71B758F6-A0AC-401D-973D-4CF044C5B045@julianstahnke.com>

> The usage of ?track? specifically in hAudio (and rightfully so) is  
> a sequential one, though. One track comes after another. So while  
> it shares the same name, it?s (to my mind) an entirely different  
> concept than a track found on a CD.

Gah! I wrote that in a very misleading way. I *don?t* mean that the  
usage of track in hAudio is entirely different than tracks on a CD.

I mean that tracks on a DVD/in a video seem to be an entirely  
different concept from tracks on a CD (from which the hAudio tracks  
are derived).
From scott at makedatamakesense.com  Sat Oct  6 12:02:55 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Sat Oct  6 12:04:41 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <85137B17-28D2-4A07-87E7-7864A39EDAEA@julianstahnke.com>
References: <46FD1623.8000802@digitalbazaar.com>	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>	<47058EB5.602@digitalbazaar.com>	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>	<4705AA3B.2020802@digitalbazaar.com>	<383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>
	<1191605497.31012.6.camel@localhost.localdomain>
	<470699CD.3050001@digitalbazaar.com>
	<85137B17-28D2-4A07-87E7-7864A39EDAEA@julianstahnke.com>
Message-ID: <F71F75D6-1B44-4D3F-9DE1-C4E2CF9E6838@makedatamakesense.com>

On Oct 6, 2007, at 12:24 PM, Julian Stahnke wrote:

> What does ?track? mean in the context of the hVideo format, though?

I think we're getting distracted here.  That's a good question for  
the hVideo discussion, but it's really irrelevant to the hAudio  
discussion.  Audio tracks need to be clearly identified as audio  
tracks regardless of what happens with hVideo, so let's focus on how  
to do that and leave hVideo for a separate discussion.

--
Scott Reynen
MakeDataMakeSense.com
From julian at julianstahnke.com  Sat Oct  6 12:42:02 2007
From: julian at julianstahnke.com (Julian Stahnke)
Date: Sat Oct  6 12:43:00 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <F71F75D6-1B44-4D3F-9DE1-C4E2CF9E6838@makedatamakesense.com>
References: <46FD1623.8000802@digitalbazaar.com>	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>	<47058EB5.602@digitalbazaar.com>	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>	<4705AA3B.2020802@digitalbazaar.com>	<383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>
	<1191605497.31012.6.camel@localhost.localdomain>
	<470699CD.3050001@digitalbazaar.com>
	<85137B17-28D2-4A07-87E7-7864A39EDAEA@julianstahnke.com>
	<F71F75D6-1B44-4D3F-9DE1-C4E2CF9E6838@makedatamakesense.com>
Message-ID: <56FF72C7-16C4-40D7-8806-956D44103C80@julianstahnke.com>

On 6 Oct 2007, at 8:02pm, Scott Reynen wrote:

> On Oct 6, 2007, at 12:24 PM, Julian Stahnke wrote:
>
>> What does ?track? mean in the context of the hVideo format, though?
>
> I think we're getting distracted here.  That's a good question for  
> the hVideo discussion, but it's really irrelevant to the hAudio  
> discussion.  Audio tracks need to be clearly identified as audio  
> tracks regardless of what happens with hVideo, so let's focus on  
> how to do that and leave hVideo for a separate discussion.

Okay. If that?s the case, then I don?t see why ?track? could not be  
just plain text?

Secondly, somewhat related, what happens if you stumble upon  
something like the following:

<div class="haudio">
     <h3 class="album">my album title</h3>
     by <strong class="contributor">the artist</strong>
     <ol>
         <li class="track">my track title</li>
         <li class="track">my track title</li>
         <li class="track">my track title</li>
     </ol>
</div>

Even though the tracks aren?t marked up as hAudio element and hence  
have no ?position? attribute, should ?position? be implied by the  
position of the track in the <ol>? (This must, obviously, never  
happen for an <ul>.) I think that would make sense and enable some  
nice, light-weight mark-up that everyone with even the most basic  
understanding of HTML could comprehend or write (and that is quite  
parseable as well).

(Also, I don?t know if the proposal to allow ?contributor? to be  
plain-text was welcomed or not. Just imagine an hcard in there in  
case it wasn?t ;))
From msporny at digitalbazaar.com  Sat Oct  6 15:54:33 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sat Oct  6 15:54:36 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <85137B17-28D2-4A07-87E7-7864A39EDAEA@julianstahnke.com>
References: <46FD1623.8000802@digitalbazaar.com>	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>	<47058EB5.602@digitalbazaar.com>	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>	<4705AA3B.2020802@digitalbazaar.com>	<383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>	<1191605497.31012.6.camel@localhost.localdomain>	<470699CD.3050001@digitalbazaar.com>
	<85137B17-28D2-4A07-87E7-7864A39EDAEA@julianstahnke.com>
Message-ID: <47081229.80403@digitalbazaar.com>

Julian Stahnke wrote:
>> If you want to push your proposal above, you will have to make the
>> following arguments:
>>
>> 1. Why Ambiguity is not an issue for TRACK.
>> 2. Why we should introduce a new property called TRACK-TITLE.
>> 3. Why we should require CONTRIBUTOR to be marked up via a VCARD.
> 
> About tracks inside hAudio/hVideo: What about assuming that the track
> has the same media type as its parent element unless declared otherwise?

That is a rule that we could certainly enforce via the parser... and it
would reduce the markup that a publisher would have to do.

Just to add a bit of implementation detail to your proposal:

An hAudio parser would then assume that the contents of TRACK is an
hAudio object if it is inside of an hAudio container. This means that
any uF markup inside of TRACK could be any of the properties of hAudio.

hAudio parsers, when seeing TRACK would create another hAudio object and
stuff the properties found in TRACK into the newly created hAudio object
for the TRACK.

Scott Reynen wrote:
>> What does ?track? mean in the context of the hVideo format, though?
> I think we're getting distracted here.  That's a good question for the
> hVideo discussion, but it's really irrelevant to the hAudio
> discussion.

I was attempting to think ahead to hVideo, but it seems to be causing
more confusion than helping. Scott's right... we should concentrate on
hAudio.

> Okay. If that?s the case, then I don?t see why ?track? could not be
> just plain text?

We could easily give publishers both options without complicating the
parser that greatly. Both of the examples below would be proper uses of
hAudio:

<div class="haudio">
    <h3 class="album">my album title</h3>
    by <strong class="contributor">the artist</strong>
    <ol>
        <li class="track">my track title</li>
        <li class="track">my track title</li>
        <li class="track">my track title</li>
    </ol>
</div>

<div class="haudio">
    <h3 class="album">3 live bands at my local venue</h3>
    by <strong class="contributor">various artists</strong>
    <ol>
        <li class="track">
           <span class="recording">first track title</a> by
           <span class="contributor">first artist</span>
        </li>
        <li class="track">
           <span class="recording">second track title</a> by
           <span class="contributor">second artist</span>
        </li>
        <li class="track">
           <span class="recording">third track title</a> by
           <span class="contributor">third artist</span>
        </li>
    </ol>
</div>

> Even though the tracks aren?t marked up as hAudio element and hence
> have no ?position? attribute, should ?position? be implied by the
> position of the track in the <ol>?

My thoughts are that it should be... but with the ability to override
the <li> numbering scheme. What happens if somebody only wants to list 3
of the items in the album... song 3, 5, and 8?

It should also be noted that the POSITION and DESCRIPTION concepts are
disputed additions to the proposal. I still need to go back through and
re-analyze the examples to prove that there is enough evidence in the
examples to add POSITION and DESCRIPTION to hAudio.

PODCAST is disputed by Martin and since I'm the only person that is
backing it based on the examples, it will probably be dropped unless
somebody else wants to see the ability to mark up PODCASTs via hAudio.
It also seems that RECORDING (was audio-title) is a disputed name
change, per Martin.

-- manu

From scott at makedatamakesense.com  Sat Oct  6 16:24:52 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Sat Oct  6 16:24:55 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <47081229.80403@digitalbazaar.com>
References: <46FD1623.8000802@digitalbazaar.com>	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>	<47058EB5.602@digitalbazaar.com>	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>	<4705AA3B.2020802@digitalbazaar.com>	<383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>	<1191605497.31012.6.camel@localhost.localdomain>	<470699CD.3050001@digitalbazaar.com>
	<85137B17-28D2-4A07-87E7-7864A39EDAEA@julianstahnke.com>
	<47081229.80403@digitalbazaar.com>
Message-ID: <D59C377F-550C-4FBE-AAB8-0E07AD90C782@makedatamakesense.com>

On Oct 6, 2007, at 4:54 PM, Manu Sporny wrote:

> PODCAST is disputed by Martin and since I'm the only person that is
> backing it based on the examples, it will probably be dropped unless
> somebody else wants to see the ability to mark up PODCASTs via hAudio.

That's assuming those who don't want a podcast class don't want to be  
able to markup podcasts, which in my case is a false assumption.  I  
don't want a podcast class because I think we can markup podcasts  
without it.  Specifically, hAtom + hAudio = a podcast.  If you see  
something missing there, please clarify what exactly.

--
Scott Reynen
MakeDataMakeSense.com


From julian at julianstahnke.com  Sat Oct  6 16:38:08 2007
From: julian at julianstahnke.com (Julian Stahnke)
Date: Sat Oct  6 16:38:13 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <47081229.80403@digitalbazaar.com>
References: <46FD1623.8000802@digitalbazaar.com>	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>	<47058EB5.602@digitalbazaar.com>	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>	<4705AA3B.2020802@digitalbazaar.com>	<383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>	<1191605497.31012.6.camel@localhost.localdomain>	<470699CD.3050001@digitalbazaar.com>
	<85137B17-28D2-4A07-87E7-7864A39EDAEA@julianstahnke.com>
	<47081229.80403@digitalbazaar.com>
Message-ID: <86B0D4A9-F1FB-4AFB-9670-503FB04F3318@julianstahnke.com>

> <div class="haudio">
>     <h3 class="album">my album title</h3>
>     by <strong class="contributor">the artist</strong>
>     <ol>
>         <li class="track">my track title</li>
>         <li class="track">my track title</li>
>         <li class="track">my track title</li>
>     </ol>
> </div>
>
> <div class="haudio">
>     <h3 class="album">3 live bands at my local venue</h3>
>     by <strong class="contributor">various artists</strong>
>     <ol>
>         <li class="track">
>            <span class="recording">first track title</a> by
>            <span class="contributor">first artist</span>
>         </li>
>         <li class="track">
>            <span class="recording">second track title</a> by
>            <span class="contributor">second artist</span>
>         </li>
>         <li class="track">
>            <span class="recording">third track title</a> by
>            <span class="contributor">third artist</span>
>         </li>
>     </ol>
> </div>

I think that, if you want to use hAudio properties inside a track, it  
actually must be an hAudio element. It must not be an hAudio element  
if you *only* want to use plain-text. Same for contributor with  
regards to hCard. Would seem most sensible to me.

>> Even though the tracks aren?t marked up as hAudio element and hence
>> have no ?position? attribute, should ?position? be implied by the
>> position of the track in the <ol>?
>
> My thoughts are that it should be... but with the ability to override
> the <li> numbering scheme. What happens if somebody only wants to  
> list 3
> of the items in the album... song 3, 5, and 8?

In that case, one would either use an unordered list (and have no  
numbering) or just use a full-blown haudio element and specify the  
position via the position property as that would *always* override  
any implied formatting. Implied formatting should accommodate for the  
most common use cases and be kept simple, I think.

It?s the same with implied fn formatting. It works fine in most  
cases, and if one wants something more fancy, one just uses given- 
name and family-name etc.

Note the use of haudio on the <li>s, I?m using properties of haudio  
instead of plain-text, so a new nested haudio element should be  
required imho.

That would result in the following mark-up:

<div class="haudio">
     <h3 class="album">3 live bands at my local venue</h3>
     by <strong class="contributor">various artists</strong>
     <ul>
         <li class="track haudio">
            <span class="position">1</span>
            <span class="recording">first track title</a> by
            <span class="contributor">first artist</span>
         </li>
         <li class="track haudio">
            <span class="position">4</span>
            <span class="recording">second track title</a> by
            <span class="contributor">second artist</span>
         </li>
         <li class="track haudio">
            <span class="position">8</span>
            <span class="recording">third track title</a> by
            <span class="contributor">third artist</span>
         </li>
     </ul>
</div>

Your example brings up something new; the various artist album case.  
 From common sense I?d say one should be able to omit the contributor  
in that case. The parser then should assume it is a various artist  
album and either say ?various artists? (less colloquial,  
obviously ;)) and/or, if available, construct it from the  
contributors in the ?track haudio? elements. The decision about what  
to do/display would then be in the hands of the person using the  
parser for his specific project.

I?m aware though that this leads to a dangerous path of assumptions  
and implications. It may be common sense and thus not very  
complicated for *me*?but someone else may think differently. Then  
again, it *really* makes sense to me. But I think we really need some  
more opinions on this case.

>> PODCAST is disputed by Martin and since I'm the only person that is
>> backing it based on the examples, it will probably be dropped unless
>> somebody else wants to see the ability to mark up PODCASTs via  
>> hAudio.
>
> That's assuming those who don't want a podcast class don't want to  
> be able to markup podcasts, which in my case is a false  
> assumption.  I don't want a podcast class because I think we can  
> markup podcasts without it.  Specifically, hAtom + hAudio = a  
> podcast.  If you see something missing there, please clarify what  
> exactly.

I haven?t given that case a lot of thinking, but I really like that  
solution. It even mirrors the technical definition of a podcast and  
makes it digestible by the whole toolchain I image one would want to  
use on it.
From paul_wilkins at xtra.co.nz  Sat Oct  6 17:27:25 2007
From: paul_wilkins at xtra.co.nz (paul_wilkins@xtra.co.nz)
Date: Sat Oct  6 17:27:29 2007
Subject: [uf-new] I propose a new microformat for poems.
Message-ID: <787886.78618.qm@web96002.mail.aue.yahoo.com>

From: Michael Walker <mike@yarrt.com>
> <div class="poem">
>    <p class="verse">
>      Standing by the roadside,<br />
>      A tall dark man,<br />
>      Wore a long brown coat,<br />
>      Stood in the rain.
>    </p>



I've never been keen with using breaks.

A
more semantically correct answer is provided with XHTML 2.0 where a
line element is defined so that awful breaks aren't required in things
like poems.
If they were used, then the poem would look like this:

<p class="verse">
  <l>Standing by the roadside,</l>
  <l>A tall dark man,</l>
  <l>Wore a long brown coat,</l>
  <l>Stood in the rain.</l>
</p>

Until such code is supported though, a modified form can be used

<p class="verse">

  <span class="l">Standing by the roadside,</span>

  <span class="l">A tall dark man,</span>

  <span class="l">Wore a long brown coat,</span>

  <span class="l">Stood in the rain.</span>

</p>


with a style of
.l { display: block; }


It's bulkier than just having breaks, but it gives warm fuzzies to the the semantic leprechaun within me.

-- 
Paul Wilkins

From msporny at digitalbazaar.com  Sat Oct  6 18:08:48 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sat Oct  6 18:08:51 2007
Subject: [uf-new] hAudio position and description properties
Message-ID: <470831A0.7070300@digitalbazaar.com>

Most of the day today was spent re-analyzing all of the music service
and podcast websites in audio-info-examples using Microformalyze. The
raw analysis data is available here:

http://microformats.org/wiki/audio-info-examples#Microformalyze_Data_Files

The analysis is available here:

http://microformats.org/wiki/audio-info-examples#Analysis_of_Music_Services

http://microformats.org/wiki/audio-info-examples#Analysis_of_Music_Podcasts

The new analysis shows very strong support for POSITION. This property
is displayed in 70.73% of 41 music service websites analyzed and 100% of
the 8 podcast websites analyzed.

There is also enough support to meet the 80/20 rule for DESCRIPTION.
This property is displayed in 39.02% of 41 music service websites
analyzed and 100% of the 8 podcast websites analyzed.

PROPOSAL: We add POSITION and DESCRIPTION to the hAudio draft since
          there are enough examples to warrant their inclusion into
          the Microformat.

-- manu
From julian at julianstahnke.com  Sat Oct  6 18:14:45 2007
From: julian at julianstahnke.com (Julian Stahnke)
Date: Sat Oct  6 18:14:51 2007
Subject: [uf-new] hAudio position and description properties
In-Reply-To: <470831A0.7070300@digitalbazaar.com>
References: <470831A0.7070300@digitalbazaar.com>
Message-ID: <316FC33D-99C3-4E8F-839C-9B3AB61F4AAD@julianstahnke.com>

> PROPOSAL: We add POSITION and DESCRIPTION to the hAudio draft since
>           there are enough examples to warrant their inclusion into
>           the Microformat.

I think you?re right and they both make perfect sense.
From martin at weborganics.co.uk  Sat Oct  6 19:47:17 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sat Oct  6 19:46:40 2007
Subject: [uf-new] hAudio position and description properties
In-Reply-To: <470831A0.7070300@digitalbazaar.com>
References: <470831A0.7070300@digitalbazaar.com>
Message-ID: <1191725237.12116.17.camel@localhost.localdomain>

On Sat, 2007-10-06 at 21:08 -0400, Manu Sporny wrote:
> Most of the day today was spent re-analyzing all of the music service
> and podcast websites in audio-info-examples using Microformalyze. The
> raw analysis data is available here:
> 
> http://microformats.org/wiki/audio-info-examples#Microformalyze_Data_Files
> 
> The analysis is available here:
> 
> http://microformats.org/wiki/audio-info-examples#Analysis_of_Music_Services
> 
> http://microformats.org/wiki/audio-info-examples#Analysis_of_Music_Podcasts
> 
> The new analysis shows very strong support for POSITION. This property
> is displayed in 70.73% of 41 music service websites analyzed and 100% of
> the 8 podcast websites analyzed.

I found No evidence of Position as far as podcasting is concerned
although all the examples make a reference to episode I am not sure that
this is the same thing, Can I also point out that podcasting Is NOT a
problem area for this discussion.

However Position Is something that should be supported As far as Music
Downloads are concerned

+1 for Position

> 
> There is also enough support to meet the 80/20 rule for DESCRIPTION.
> This property is displayed in 39.02% of 41 music service websites
> analyzed and 100% of the 8 podcast websites analyzed.

+1 for Description

> 
> PROPOSAL: We add POSITION and DESCRIPTION to the hAudio draft since
>           there are enough examples to warrant their inclusion into
>           the Microformat.
> 
> -- manu

Manu are you also going to REMOVE the Album and Podcast properties and
revert back to *audio-title* until any disputes have been resolved? I do
not think that three votes was enough to warrant any changes to the
existing proposal.

I think you should have notified all the active participants in hAudio
BEFORE you made any changes to OUR proposition.

Thanks

Martin
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From martin at weborganics.co.uk  Sun Oct  7 12:30:39 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sun Oct  7 12:30:05 2007
Subject: [uf-new] hAudio position and description properties
In-Reply-To: <1191725237.12116.17.camel@localhost.localdomain>
References: <470831A0.7070300@digitalbazaar.com>
	<1191725237.12116.17.camel@localhost.localdomain>
Message-ID: <1191785439.18330.16.camel@localhost.localdomain>

On Sun, 2007-10-07 at 03:47 +0100, Martin McEvoy wrote:
> On Sat, 2007-10-06 at 21:08 -0400, Manu Sporny wrote:
> > Most of the day today was spent re-analyzing all of the music service
> > and podcast websites in audio-info-examples using Microformalyze. The
> > raw analysis data is available here:
> > 
> > http://microformats.org/wiki/audio-info-examples#Microformalyze_Data_Files
> > 
> > The analysis is available here:
> > 
> > http://microformats.org/wiki/audio-info-examples#Analysis_of_Music_Services
> > 
> > http://microformats.org/wiki/audio-info-examples#Analysis_of_Music_Podcasts
> > 
> > The new analysis shows very strong support for POSITION. This property
> > is displayed in 70.73% of 41 music service websites analyzed and 100% of
> > the 8 podcast websites analyzed.
> 
> I found No evidence of Position as far as podcasting is concerned
> although all the examples make a reference to episode I am not sure that
> this is the same thing, Can I also point out that podcasting Is NOT a
> problem area for this discussion.
> 
> However Position Is something that should be supported As far as Music
> Downloads are concerned
> 
> +1 for Position
> 
> > 
> > There is also enough support to meet the 80/20 rule for DESCRIPTION.
> > This property is displayed in 39.02% of 41 music service websites
> > analyzed and 100% of the 8 podcast websites analyzed.
> 
> +1 for Description
> 
> > 
> > PROPOSAL: We add POSITION and DESCRIPTION to the hAudio draft since
> >           there are enough examples to warrant their inclusion into
> >           the Microformat.
> > 
> > -- manu
> 
> Manu are you also going to REMOVE the Album and Podcast properties and
> revert back to *audio-title* until any disputes have been resolved? I do
> not think that three votes was enough to warrant any changes to the
> existing proposal.
> 
> I think you should have notified all the active participants in hAudio
> BEFORE you made any changes to OUR proposition.

Sorry for seeming unreasonable but the additions of Album and Recording
really was a bit of a surprise to me and something that wasn't fully
discussed

Anyway An easy solution  The beginning of this conversation was about
(in a nutshell) merging certain properties from  hAlbum into hAudio
right! so why don't we just do that 

>From hAlbum we reuse both 

*album-title*
http://microformats.org/wiki/audio-album-proposal#Album_Title

and 

*track*
http://microformats.org/wiki/audio-album-proposal#Track 

coupled with new properties

*position*  and *description*

merge all that with the 0.6 version of hAudio and I think we have
something that will suit everyone's situation

The full property list would be

hAudio
album-title
contributor
published
rel-sample
rel-enclosure
rel-payment
photo
track
audio-title
duration
category
price

Comments?


Thanks 
Martin

> 
> Thanks
> 
> Martin
> > _______________________________________________
> > microformats-new mailing list
> > microformats-new@microformats.org
> > http://microformats.org/mailman/listinfo/microformats-new

From martin at weborganics.co.uk  Sun Oct  7 12:32:30 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sun Oct  7 12:31:53 2007
Subject: [uf-new] hAudio position and description properties
In-Reply-To: <1191785439.18330.16.camel@localhost.localdomain>
References: <470831A0.7070300@digitalbazaar.com>
	<1191725237.12116.17.camel@localhost.localdomain>
	<1191785439.18330.16.camel@localhost.localdomain>
Message-ID: <1191785550.18330.18.camel@localhost.localdomain>

On Sun, 2007-10-07 at 20:30 +0100, Martin McEvoy wrote:
> On Sun, 2007-10-07 at 03:47 +0100, Martin McEvoy wrote:
> > On Sat, 2007-10-06 at 21:08 -0400, Manu Sporny wrote:
> > > Most of the day today was spent re-analyzing all of the music service
> > > and podcast websites in audio-info-examples using Microformalyze. The
> > > raw analysis data is available here:
> > > 
> > > http://microformats.org/wiki/audio-info-examples#Microformalyze_Data_Files
> > > 
> > > The analysis is available here:
> > > 
> > > http://microformats.org/wiki/audio-info-examples#Analysis_of_Music_Services
> > > 
> > > http://microformats.org/wiki/audio-info-examples#Analysis_of_Music_Podcasts
> > > 
> > > The new analysis shows very strong support for POSITION. This property
> > > is displayed in 70.73% of 41 music service websites analyzed and 100% of
> > > the 8 podcast websites analyzed.
> > 
> > I found No evidence of Position as far as podcasting is concerned
> > although all the examples make a reference to episode I am not sure that
> > this is the same thing, Can I also point out that podcasting Is NOT a
> > problem area for this discussion.
> > 
> > However Position Is something that should be supported As far as Music
> > Downloads are concerned
> > 
> > +1 for Position
> > 
> > > 
> > > There is also enough support to meet the 80/20 rule for DESCRIPTION.
> > > This property is displayed in 39.02% of 41 music service websites
> > > analyzed and 100% of the 8 podcast websites analyzed.
> > 
> > +1 for Description
> > 
> > > 
> > > PROPOSAL: We add POSITION and DESCRIPTION to the hAudio draft since
> > >           there are enough examples to warrant their inclusion into
> > >           the Microformat.
> > > 
> > > -- manu
> > 
> > Manu are you also going to REMOVE the Album and P