audio-info-issues

From Microformats Wiki
Jump to navigation Jump to search

Audio info issues

This page defines the current issues with the hAudio draft specification. Any issues that have not yet been resolved are marked with an open issue! tag.

Contributors

In order of contribution:

Problem: Display properties of rel-patterns

hAudio ISSUE #4: open issue!

In order to solve the graphic-only buttons in rel-patterns problem, it was identified that part of the problem dealt with attempting to create relationship quadruples, or incorrect relationship triples.

If there is no text to display, then how does one place the item into a menu/display for Operator/Firefox? Grabbing the image and placing it in a UI is a difficult argument to make - there are a variety of image sizes that might not do well in the Operator UI (or Firefox 3 UI).

Typically, rel-patterns are created by doing something like the following: 

<a rel="RELATIONSHIP" href="URL">TARGET</a>

The final triple that is created can be read thusly: URL is related to TARGET via RELATIONSHIP. 

<a rel="brother" href="/people/john_f_kennedy.html">Robert Kennedy</a>

The URL above would be read like so: The URL http://www.people.org/john_f_kennedy.html is related to Robert Kennedy via a relationship of type brother. In other words, John F. Kennedy is Robert Kennedy's brother.

Using rel-pattern as such: 

<a rel="brother" href="/people/john_f_kennedy.html" title="Robert Kennedy">
  <img src="/images/robert_kennedy.gif" alt="Robert Kennedy" />
</a>

It isn't defined if the displayable value of the relationship "Robert Kennedy" should be used from

  • the @alt attribute on the IMG element
  • the @title attribute on the anchor (A element)
  • or, not at all.

This is because the rel attribute is only concerned with the relationship between the current page and the href. The TITLE of the link is not defined by rel.

It is quite often that a site uses an image instead of a text link to present actions. For example: Instead of using the text "Download", they will use a graphic image with a downward-facing arrow.

How do we present this option to a human being in a non-web-page UI?

Possible Solutions

Do nothing

The decision should be left up to uF implementors. The market should decide how the information is displayed. This is something that does not need to be explicit in the spec, but can be left flexible to developers to implement as they see best and to adapt to their applications and future developments. Forcing someone to use the @alt or @title prevents them from reusing the actual image or using their own graphics because the spec mandated the "correct" use.

Not Specified but Publish hAudio Best Practices Section

This is a slight variation on the "Do nothing" approach. Implementation is still left up to the uF/application implementors, but we recommend the following in a "Best Practices" section for hAudio: 

Authors should use the "title" attribute to provide a human readable 
description of the type of support pointed to by the hyperlink. 
Aggregators may use the contents of the "title" attribute to provide 
additional information about the support link to their users. 
 E.g. <a href="[url]" rel="payment" title="Donate Money Via PayPal">.
  • If TITLE is not used, the link text that is displayed in a text-only web browser should be used.

Use the TITLE Attribute

Using @title was proposed in the following post to the mailing list:

http://microformats.org/discuss/mail/microformats-new/2007-July/000590.html

Benefits
  1. It POSH-ifies the website.
  2. It works well with Operator, Firefox 3 and other uF parsers/UIs.
  3. It adds the accessibility/screen reader problem.
Drawbacks
  1. There are arguments stating that the @alt attribute would be a better choice: http://microformats.org/discuss/mail/microformats-new/2007-July/000593.html
  2. there are arguments that this is not part of how the rel attribute was designed and it is layering semantics onto the attribute that don't exist in the HTML spec.

New Label Property

Create a specific new property that defines the label title, or other displayable Microformat class that should specify the text value to be used.

Feedback

  • +1 for not specifying, but providing best practices section ManuSporny 06:54, 14 Aug 2007 (PDT)
  • +1 for Do Nothing recommend proper use of @alt Martin McEvoy 16:03, 14 Aug 2007 (GMT)

Problem: Peeking into child elements

hAudio ISSUE #5: open issue!

It has been proposed that peeking into child elements that are not labeled with microformatted class names goes against the established publishing practices of microformats. In other words, if there isn't a microformatted class name on the element, we shouldn't be reading/interpreting the contents of the element.

There have been several proposed solutions, one of which automatically peeks at certain sub-elements, such as @alt in IMG: 

<a rel="license" href="http://creativecommons.org/licenses/by/3.0/">
  <img src="/images/deed/by.png" alt="Creative Commons Attribution 3.0" />
</a>

A microformat parser would take the HTML above and automatically parse out the contents of the @alt attribute on all child elements.

Another approach would parse out display-able elements based on a pre-defined microformatted relationship such as displayble, like so: 

<a rel="license" href="http://creativecommons.org/licenses/by/3.0/">
  <img rel="displayable" src="/images/deed/by.png" alt="Creative Commons Attribution 3.0" />
</a>

Possible Solutions

  1. Microformats should never peek into child elements when displaying information.
  2. The community should decide on a set of attributes and elements that are peek-able (for example: any element that contains an @alt attribute should be peek-able)
  3. Only elements that are marked with a class of a specified type, such as displayable, should be used to display the text.
  4. Display what common text-only browser displays (in the case of Lynx, the value in @alt).

Benefits

  1. Valid HTML requires that the ALT tag is specified anyway, thus we're helping people write proper HTML.
  2. Because of the item above, this is in-line with what most text-based browsers and screen readers expect.
  3. There is no danger of @title and @alt both being specified and read by a screen reader.
    1. ?? what about @title on the 'a' and an @alt on the image?

Drawbacks

  1. The point was raised that ALT tags are not used properly on the web: http://microformats.org/discuss/mail/microformats-new/2007-July/000598.html and http://microformats.org/wiki/hcard-faq#Why_is_IMG_alt_not_being_picked_up

Feedback

  • +1 for displaying what a common text-only browser or screen reader would display ManuSporny 06:46, 14 Aug 2007 (PDT)
  • +1 Display what common text-only browser displays Martin McEvoy 15:58, 14 Aug 2007 (GMT)

Resolved Issues

Problem: image-summary Property

hAudio ISSUE #1: resolved issue

image-summary - This is a small graphic image that summarizes the audio piece. It should NOT be a MUST to use the <img> element, (it shouldn't be a MUST anyway) ~BrianSuda. There are several other formats that already use the PHOTO property, including hCard and hReview. This has potential to collapse and remove image-summary.

Possible Solutions

  1. Use PHOTO instead.

Feedback

Resolution

PHOTO has been used to replace IMAGE-SUMMARY in the latest proposal, reusing a previous Microformat property, which is a Good Thing(tm).

Problem: audio-title Property

hAudio ISSUE #2: resolved issue

audio-title - There is an on going debate where this should be something else such as FN or SUMMARY, or RECORDING.

Possible Solutions

  1. Use FN instead
  2. Use SUMMARY instead
  3. Use RECORDING instead for singular audio recordings (songs, movements, chapters) and ALBUM/RELEASE for collections of audio recordings.

Feedback

  • +1 : use RECORDING and ALBUM ManuSporny 18:20, 27 Sep 2007 (PDT)
  • -1 : don't change audio-title Martin McEvoy 15:48, 14 Aug 2007 (GMT)
  • +1 for using FN, no clear difference between two so why invent another David Janes 14 August 2007

Resolution

FN has been used to replace AUDIO-TITLE in the latest proposal, reusing a previous Microformat property.

Problem: published-date Property

hAudio ISSUE #3: resolved issue

published-date is a duplicate of the PUBLISHED property found-in hAtom. This can be collapsed to a single property name

Alternatively, we could use dtstart, from hCalendar (shouldn't the published date be an hCalendar event?) Andy Mabbett

Possible Solutions

  1. Use PUBLISHED instead
  2. Use DTSTART instead

Feedback

  • +1 for using PUBLISHED instead of PUBLISHED-DATE ManuSporny 06:41, 14 Aug 2007 (PDT)
  • +1 for using PUBLISHED instead of PUBLISHED-DATE Martin McEvoy 15:51, 14 Aug 2007 (GMT)

Resolution

PUBLISHED has been used to replace PUBLISHED-DATE in the latest proposal, reusing a previous Microformat property, which is a Good Thing (tm).

Problem: Summary Property is Missing

hAudio ISSUE #6: resolved issue

Martin McEvoy did another analysis run of the audio-info-examples data and found that audio descriptions existed for many of the examples. It has been proposed that audio descriptions should be added to the hAudio Microformat.

Possible Solutions

  • Add audio descriptions to the hAudio specification using SUMMARY
  • Add audio descriptions to the hAudio specification using DESCRIPTION

Feedback

  • +1 for using DESCRIPTION ManuSporny 06:45, 14 Aug 2007 (PDT)
  • +1 for using DESCRIPTION Martin McEvoy 15:46, 14 Aug 2007 (GMT)

Resolution

DESCRIPTION has been added to the latest proposal.

Problem: Track Number is Missing

hAudio ISSUE #7: resolved issue

We assumed that the track number was going to be encapsulated by XOXO in the beginning, but it seems as if this is not the case. Unfortunately, we didn't analyze the number of sites that had tracks in them. We should do this and report our findings to the mailing list. It is also important to note that most of the audio formats support track numbers.

Possible Solutions

  • Gather examples and add track-number to hAudio if there is enough evidence to support it.

Resolution

It was announced that a re-analysis of the track-number in the audio-info-examples showed widespread support for a positional element. POSITION has been added to the hAudio proposal and was supported by Manu Sporny, Julian Stanhke, and Martin McEvoy with no opposition.

Problem: hAlbum is redundant

hAudio ISSUE #8: resolved issue

Most of hAlbum's properties overlap with hAudio. In fact, the only two properties that do not overlap with hAudio are 'album-title' and 'track'.

Possible Solutions

It has been proposed that we merge these two properties into hAudio to provide a cleaner, more unified way of describing audio songs and albums. Examples of how this would work are below:

You can specify an hAudio album instead of an hAudio song by specifying the 'album-title' property and not including the 'audio-title' property: 

<div class="haudio">
   <span class="album-title">Underdog World Strike</span> by 
   <div class="collaborator">
      <div class="vcard">
         <span class="org fn">Gogol Bordello</span>
      </div>
   </div>
</div>

You can specify an audio song that belongs to an audio album by specifying both 'album-title' and 'audio-title': 

<div class="haudio">
   <span class="audio-title">Start Wearing Purple</span>
   is a song off of the album
   <span class="album-title">Underdog World Strike</span> by 
   <div class="collaborator">
      <div class="vcard">
         <span class="org fn">Gogol Bordello</span>
      </div>
   </div>
</div>

You can specify each track in an album by including one or more 'track' properties and specifying the 'album-title': 

<div class="haudio">
   <img class="photo" src="images/live_phish_vol_15.jpg"/>
   <span class="album-title">Live Phish, Volume 15</span>
   <span class="contributor">
      <span class="vcard">
         <span class="fn org">Phish</span>
      </span>
   </span>
   <br/>
   Released on:
   <abbr class="published" title="20023110">October 31, 2002<abbr>
   <br/>
   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>
   Category: <span class="category">live</span>
   Duration: <abbr class="duration" title="P8727S">145 minutes, 27 seconds</abbr>
   Price: <span class="money">
             <abbr class="currency" title="USD">$</abbr>
             <span class="amount">14.99</span>
          </span>
   Tracks:
   <span class="track">1.
    <span class="haudio>
     <span class="audio-title">Sanity</span> 
     (<abbr class="duration" title="P348S">5:48</abbr>)
     </span>
    </span>
   </span>
   <span class="track">2.
    <span class="haudio>
     <span class="audio-title">Highway To Hell</span> 
     (<abbr class="duration" title="P219S">3:39</abbr>)
     </span>
    </span>
   </span>
</div>

Parsing rules would have to be changed slightly:

  • If only 'album-title' is specified, then the hAudio is an album.
  • If only 'audio-title' is specified, then the hAudio is a song/speech or other singular work.
  • If both 'album-title' and 'audio-title' is specified, then the hAudio is a song that is part of an album.
  • If 'album-title' and one or more 'track's are specified, the hAudio is an album containing tracks. Each track is a hAudio. None of the track properties should implicitly be added to the hAudio. In other words, the parser shouldn't parse the contents of the 'track' hAudio into the non-track hAudio object.

This also allows us to easily extend hAudio into the realm of podcasts, toplists, and other types of audio collections by adding a "*-title" property. For example, we could extend hAudio to support podcasts and podcast sections by adding a single property to hAudio: 'podcast-title'. 'track' would be used for each podcast section, in that use case.

Feedback

  • +1 for merging 'album-title' and 'track' into hAudio from hAlbum. ManuSporny 12:57, 8 Sep 2007 (PDT)
  • +1 also for merging album-title and track into hAudio Martin McEvoy 21:48, 8 Sep 2007 (GMT+1)
  • +1 also for merging album-title and track into hAudio Chris Newell 12:11, 25 Sep 2007 (GMT+1)

Resolution

We now have the ALBUM-TITLE and TRACK elements in hAudio, there is no longer a need for hAlbum.

Problem: album-title Property

hAudio ISSUE #9: resolved issue

It has been proposed that something else should be used instead of album-title.

Possible Solutions

  1. Use ALBUM instead of ALBUM-TITLE
  2. Use RELEASE instead of ALBUM-TITLE
  3. Keep ALBUM-TITLE

Feedback

Problem: Collection Names

hAudio ISSUE #10: resolved issue

The following have been proposed for collection names if hAlbum is going to be integrated into hAudio.

Possible Solutions

  • ALBUM-TITLE, ALBUM, or RELEASE - used for vinyl albums, CD singles, Ringles (haha), EPs, and CDs.
  • PODCAST - used for podcasts.
  • TOPLIST, CHART - used for top 10, top 40 and lists of audio recordings. Can be re-used for television, short film and video recordings in the future.
  • PLAYLIST - used to contain a grouped list of audio recordings and video recordings. Could be re-used for television episodes, short films, and video recordings in the future.
  • TRACK - used for each item in the audio-recording collection above.

Feedback

Resolution

The latest proposal uses ALBUM, which seemed to have the least amount of push-back from the mailing list.

Problem: CONTRIBUTOR and TRACK are not publisher friendly

hAudio ISSUE #12: resolved issue

In order to specify a CONTRIBUTOR or TRACK, a publisher must use VCARD or HAUDIO mark up. This is annoying if the only piece of information being marked up is that of the artist name or the track name, which is usually what happens in most blog postings. We should provide a mechanism to make it easier for a publisher to blog about an album with a contributor or a track.

Possible Solutions

We could enable this behavior by allowing the following short-form for TRACK, in addition to the HAUDIO long-form: 

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

and the following short-form for CONTRIBUTOR, in addition to the VCARD long-form: 

<span class="contributor">Phish</span>
  • Make CONTRIBUTOR and TRACK accept short-forms that do not require VCARD or HAUDIO markup.

Feedback

  • +1 for making CONTRIBUTOR and TRACK easier to specify by allowing the short-form representation ManuSporny 20:03, 4 Oct 2007 (PDT)
  • +1 Julian Stahnke 11 October 2007

Resolution

Short forms for CONTRIBUTOR and TRACK are proposed in the newest proposal and doesn't seem to cause any parsing problems or compatibility issues with other Microformats.

Problem: TRACK does not work in tables

hAudio ISSUE #11: resolved issue

Julian Stahnke noted that the new track proposal doesn't work with tables . The previous examples required one to mark up track information using haudio, thus the publisher would have to do the following to mark up a track: 

   <span class="track">1.
    <span class="haudio>
    ...
    </span>
   </span>

The nested approach above doesn't work when working with HTML tables because TR is usually the containing element of a track in the audio examples and nothing but a TD element is allowed inside of it. In other words, HAUDIO cannot be nested inside of TRACK in a table.

Possible Solutions

One approach lets HAUDIO to co-exist with TRACK. Here is an example of valid markup using this approach: 

 <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>

Note that in the above example, order doesn't matter since we are stating that a TRACK *is* HAUDIO.

  • Allow HAUDIO to co-exist with TRACK

Feedback

  • +1 for allowing HAUDIO to co-exist with TRACK ManuSporny 19:52, 4 Oct 2007 (PDT)

Resolution

When the decision to use ITEM was made, this problem became a non-issue. hAudio works in tables without any issues.

Problem: Container property naming

hAudio ISSUE #13: resolved issue

We need some sort of "container" to hold track/song information in an hAudio album. The contents of this "container" will be another hAudio chunk or text (which will be the FN of an hAudio object).

There are two proposals that are on the table right now. The end result and semantics for hAudio are the same, the only thing that we are discussing is the name of that "container". The current proposals are for:

TRACK or ITEM

Proposal for TRACK

Using TRACK means creating a new Microformat property that, while specific, is not re-using ITEM. There is also contention over whether this accurately describes a part of an album or part of a recording (in the case of a speech).

Benefits

  • TRACK is semantically accurate when describing albums, which is the only example use-case that we are attempting to solve with hAudio.
  • No other changes to other Microformats or definitions are required.

Drawbacks

  • TRACK has multiple meanings.
  • TRACK is not accurate when describing parts of a speech, orchestral movement, or other non-album collection of audio.
  • It is a new property that we must create.

Proposal for ITEM

Using ITEM as the container element means that we will be changing the current definition of ITEM.

We don't want to break backwards compatability, so we have to work with the current definitions of item for hReview and hListing by defining ITEM as the following, which can be used across all Microformats:

ITEM - A generic method that Microformats use for unordered containment of other Microformat properties or objects. This property MUST have, at a minimum, the name of the item. The name of the item can be specified using either:

  1. plain-text, if the property contains only the name of the item.
  2. "fn", if the property contains multiple Microformat properties.

ITEM MAY contain other properties/Microformats, but anything other than FN must be defined by the Microformat that is using ITEM.

The above definition doesn't require hReview or hListing to change at all. It also means that we can use it like so in hAudio:

Single track, with known album (same as putting text in the ‘album’ field of an ID3 tag): 

<span class="haudio">
    <span class="fn">Nagasaki Nightmare</span>
    <span class="album">Best Before 1984</span>
    <span class="contributor">Crass</span>
</span>

Single track, album unknown: 

<span class="haudio">
    <span class="fn">Nagasaki Nightmare</span>
    <span class="contributor">Crass</span>
</span>

Album: 

<span class="haudio">
    <span class="fn album">Best Before 1984</span>
    <span class="contributor">Crass</span>
</span>

Album with a couple of tracks, simple example: 

<span class="haudio">
    <span class="fn album">Best Before 1984</span>
    <span class="contributor">Crass</span>
    <span class="item">Nagasaki Nightmare</span>
    <span class="item">Hokkaido Dream</span>
    <span class="item">Tokyo Groove</span>
</span>

Album with a couple of tracks, more detailed: 

<span class="haudio">
    <span class="fn album">Best Before 1984</span>
    <span class="contributor">Crass</span>
    <span class="item haudio"><span class="fn">Nagasaki Nightmare</span>
– <abbr class="duration" title="P268S">4:46</abbr></span>
    <span class="item haudio"><span class="fn">Hokkaido Dream</span>
– <abbr class="duration" title="P268S">4:46</abbr></span>
    <span class="item haudio"><span class="fn">Tokyo Groove</span>
– <abbr class="duration" title="P268S">4:46</abbr></span>
</span>

Benefits

  • ITEM is a new bag/set/container item that can be re-used across all Microformats is created.
  • The new definition of ITEM is backwards-compatible.

Drawbacks

  • ITEM is being re-defined, which is somewhat against the Microformat principles.
  • ITEM is not semantically accurate unless it is paired with an hAudio element.

Feedback

  • +1 for TRACK ManuSporny 13:56, 14 Oct 2007 (PDT)
  • +1 for ITEM JustinMaxwell 14:14, 14 Oct 2007 (PDT)
  • +1 for ITEM Martin McEvoy 22:21, 14 Oct 2007 (GMT)
  • +1 for TRACK --jeffmcneill 14:35, 14 Oct 2007 (PDT) (that is if I have a vote, I have only been lurking on the discussion)

Resolution

ITEM is being re-used from the hReview Microformat and is in the current proposal.

Historical: Graphic buttons in rel-patterns

Affected Parties

Any site that uses images for links. 'rel-sample', 'rel-enclosure', and 'rel-payment' and wants an additional property to display something besides a URL are affected. Most of the examples also contain images instead of text for samples, downloads and purchase links. This is a demonstrable, widespread problem.

This problem has been split into two parts, per Brian Suda's request. The problems are listed above and refer to this problem statement, namely:

Display properties of rel-patterns and Peeking into child elements

History

  1. ALT was proposed on the mailing list
  2. The point was raised that ALT tags are not used properly on the web
  3. Research was started on ALT tag usage on the web and [1]
  4. Analysis on ALT tag usage on the web was reported and [2]
  5. A very long argument started on the use/mis-use of ALT
  6. More research was performed and presented to the list asserting that ALT is not being mis-used on the web
  7. It was asserted that the research completed was not acceptable
  8. Things got nasty
  9. Posting stopped due to an End of Thread request
  10. The issue and discussion was documented on the wiki.

Related Pages

Retrieved from "http://microformats.org/wiki/index.php?title=audio-info-issues&oldid=33292"