Hello all
I have left this issue until last because this is the longest and
probably the most contentious issue of them all issue D2 hAudio Title[1]
originally marked as Overloading fn
The current discussion around hAudio Title[2] is at the moment that It
can't be used because its already
Martin McEvoy wrote:
I will be closing issues D1, D3, and D4 today the solutions are
outlined below.
+1 to all of your proposed solutions, Martin. Great work on closing
these last remaining issues! :)
-- manu
--
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.0 Website
Martin,
The first option you provide illustrates the fundamental problem with this
issue, which is that the meaning we are trying to express is the name of the
track / hAudio item. Even the iTunes UI refers to the Name (select a track in
iTunes, Get Info, click the Info tab, note the first
Martin McEvoy wrote:
-
Resoulution 2:
Use HTITLE
[...]
hTitle can then be reused in any microformat that needs a title
property. hTitle has been given a root class
Manu Sporny wrote:
Martin McEvoy wrote:
I will be closing issues D1, D3, and D4 today the solutions are
outlined below.
+1 to all of your proposed solutions, Martin. Great work on closing
these last remaining issues! :)
Thank you Manu, I didnt do it on my own just nudged you
Hello Tantek
Tantek Celik wrote:
Martin,
The first option you provide illustrates the fundamental problem with this issue, which
is that the meaning we are trying to express is the name of the track / hAudio item. Even
the iTunes UI refers to the Name (select a track in iTunes, Get Info,
Martin McEvoy wrote:
Hello Tantek
Tantek Celik wrote:
Martin,
The first option you provide illustrates the fundamental problem with
this issue, which is that the meaning we are trying to express is the
name of the track / hAudio item. Even the iTunes UI refers to the
Name (select a track
Manu Sporny wrote:
Martin McEvoy wrote:
-
Resoulution 2:
Use HTITLE
[...]
hTitle can then be reused in any microformat that needs a title
property. hTitle has been given
On [Sep 1], at [ Sep 1] 2:00 , Martin McEvoy wrote:
fn was changed to title because it was over used in haudio,
haudio title = fn
haudio contributor = fn
item title = fn
and what If the author of the audio came first?
This shouldn't be an issue. Every hAudio parser must understand
Hello Scott
Scott Reynen wrote:
On [Sep 1], at [ Sep 1] 2:00 , Martin McEvoy wrote:
fn was changed to title because it was over used in haudio,
haudio title = fn
haudio contributor = fn
item title = fn
and what If the author of the audio came first?
This shouldn't be an issue. Every
Martin,
I agree with you that this is a larger issue impacting existing and new
microformats, however, trying to come up with new names for the same meaning is
not the answer, and will quickly fall apart.
We likely need to come up with scoping rules for all microformats like (just
thinking
On Mon, Sep 1, 2008 at 7:34 PM, Tantek Celik [EMAIL PROTECTED] wrote:
Martin,
I agree with you that this is a larger issue impacting existing and new
microformats, however, trying to come up with new names for the same meaning
is not the answer, and will quickly fall apart.
We likely need
Tantek Celik wrote:
I agree with you that this is a larger issue impacting existing
and new microformats, however, trying to come up with new names
for the same meaning is not the answer, and will quickly fall apart.
*sigh* - and we were so close to getting hAudio to the draft stage... I
It is my duty to point out that this issue comes up every six months.
In the past, it has always been tabled for a variety of reasons. Maybe
this will be the last time I exercise this office.
As someone who consumes ufs, my +1 is for a top-level, generic scoping
class of a single name used
Hello again Tantek
Tantek Celik wrote:
Martin,
I agree with you that this is a larger issue impacting existing and new
microformats, however, trying to come up with new names for the same meaning is
not the answer, and will quickly fall apart.
Agreed
We likely need to come up with
15 matches
Mail list logo
