haudio-issues: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
Line 47: Line 47:
*#* A proposal for this issue was first made in this email http://microformats.org/discuss/mail/microformats-new/2008-August/001715.html
*#* A proposal for this issue was first made in this email http://microformats.org/discuss/mail/microformats-new/2008-August/001715.html
*#* A second proposal for this issue has been made in this email http://microformats.org/discuss/mail/microformats-new/2008-August/001727.html
*#* A second proposal for this issue has been made in this email http://microformats.org/discuss/mail/microformats-new/2008-August/001727.html
*#* This can potentially be solved by recognition of downloadable/streamable MIME types. For performance reasons it is undesirable for parsers to be required to make HTTP requests for each file to determine its MIME type, so authors should be encouraged to include the MIME type in the <code>type</code> attribute. See the [[haudio-brainstorming#Download_links|related section on "brainstorming"]]. [[User:TobyInk|TobyInk]] 14:41, 20 Aug 2008 (PDT)
</div>
</div>
</div>
</div>

Revision as of 21:41, 20 August 2008

hAudio issues

These are externally raised issues about hAudio with broadly varying degrees of merit. Thus some issues are rejected for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be accepted and perhaps cause changes or improved explanations in the spec.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible.

issues

Please add new issues to the bottom of the list by copy and pasting the Template. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

  • You can subscribe to all haudio issues on webcal://feeds.technorati.com/events/http://microformats.org/wiki/haudio-issues

2008

D1: 2008-01-10 Contributor

D2: 2008-01-10 Overloading "fn".

D3: 2008-01-10 Position.

    1. The recommended use of "position" in hAudio is contrary to the good practice, semantic use of ordered lists (see example and suggested solution in the above e-mail; also [2] et seq)
      • For Cognition I'm considering an extension: if no position has been explicitly marked up, and the item is <li class="item"> within an ordered list, then the position is taken to be the numerical value of the list marker. (To calculate the numerical value for the list marker, find the most recent sibling <li> element which has a value attribute. The numerical value is the number in that value attribute added to the count of <li> elements after that value attribute up to the current one. If there are no such <li> elements with value attributes, then you should assume that the value attribute of the first list item is equal to the start attribute of the ordered list itself, or "1" if there is no such start attribute. TobyInk 04:24, 29 Jul 2008 (PDT)
      • Martin McEvoy has recommended that this issue be marked as Closed as it was resolved in this email: ( http://microformats.org/discuss/mail/microformats-new/2008-August/001707.html)

D4: 2008-01-10 rel-enclosure does not allow for links to streaming files

D5: 2008-01-10 there is no way of linking to an interim page

    1. There appears to be no mechanism to mark up an hAudio, expressed in plain text on page A, which links to an interim page, B, which in turn links to a file download. For example, the radio shows listed on [3].


D6: 2008-01-10 hAudio notes inconsistency

template

Consider using this format (copy and paste this to the end of the list to add your issues; replace ~~~ with an external link if preferred) to report issues or feedback, so that issues can show up in hAtom subscriptions of this issues page. If open issues lack this markup, please add it.

Please post one issue per entry, to make them easier to manage. Avoid combining multiple issues into single reports, as this can confuse or muddle feedback, and puts a burden of separating the discrete issues onto someone else who 1. may not have the time, and 2. may not understand the issue in the same way as the original reporter.

<div class="hentry">
{{OpenIssue}} 
<span class="entry-summary author vcard">
 <span class="published">2011-MM-DD</span> 
 raised by <span class="fn">~~~</span>
</span>
<div class="entry-content discussion issues">
* <strong class="entry-title">«Short title of issue»</strong>. «Description of Issue»
** Follow-up comment #1
** Follow-up comment #2
</div>
</div>

see also

related pages