convert mf2 length and size properties to RSS duration and length

[snarfed]

...except we have no clear mf2 standard yet for either one. discussion: https://chat.indieweb.org/dev/2019-08-08#t1565286782453800

https://indieweb.org/podcast shows two examples in the wild with length: aaronpk's is integer seconds, @gRegorLove's is PT1H7M59S. (what even is that?)

...and two examples with size, different human-readable versions: @aaronpk's 17.43mb, @gRegorLove's 62.2 MB.

RSS spec for length (integer bytes): http://www.rssboard.org/rss-specification#ltenclosuregtSubelementOfLtitemgt

iTunes details for duration (integer seconds): https://help.apple.com/itc/podcasts_connect/#/itc2b3780e76 , and example RSS: https://help.apple.com/itc/podcasts_connect/#/itcbaf351599

cc @jgmac1106

[Zegnat]

@gRegorLove's is PT1H7M59S. (what even is that?)

An ISO 8601 duration: PnYnMnDTnHnMnS. Or more likely the derived HTML duration syntax. Though it is basically the same here. (I’d also argue it should have used a <time> element, but that’s a separate issue 😉 )

I feel like this has been discussed as mf2 properties, but can’t seem to find anything right now.

[dshanske]

mf2 duration is iso8601 duration in my humble opinion. Agree on size having no standard

[Zegnat]

https://indieweb.org/podcast shows two examples in the wild with length: aaronpk's is integer seconds […]

Where does @aaronpk do this? When I look at Percolator it uses p-duration:

<div class="podcast-meta">
  <a href="/episode/24" class="u-url">
    <time class="dt-published" datetime="2019-06-13">
      June 13, 2019
    </time>
  </a>
  &nbsp;&nbsp;•&nbsp;&nbsp; 
  <data class="p-duration" value="875">
    14m35s
  </data> 
  / 
  <span class="p-size">17.41mb</span>
</div>

[17:53] huh. now that i'm digging more, i can't find where i got that dt-duration is appropriate for u-video/audio. not seeing it on microformats.org or the wiki

duration is a property of the old hAudio object. That page also specifies it should use the ISO 8601 format that @gRegorLove is using. It was actually copied from the old hCalendar.

Interesting enough, when h-event added dt-duration (and backwards compatible parsing of hCalendar’s duration as dt-duration) it dropped all mention of what format to expect of the value. That is probably worth a separate issue on microformats/h-event.

---

I think the correct HTML+mf2 for marking up the play length of an audio/video segment should be:

<time class="dt-duration" datetime="PT14M35S">14 minutes and 35 seconds</time>

The question then becomes how you would connect this with any one specific u-audio or u-video property. As there could be several of those. But that touches on some of the same points that have been raised around poster frames for videos.

[snarfed]

aaronpk's is integer seconds […]

Where does @aaronpk do this?

i was just reporting this, which says he does: https://indieweb.org/podcast#How_to_podcast_with_h-feed . i hadn't actually checked his markup.

[jgmac1106]

Can we just pick? dt-duration sounds settled and p-size works...just be nice to pass an itunes validator with an mf2 podcast feed

[snarfed]

ok! thanks for the discussion all. i've deployed preliminary support for reading and writing duration mf2 (and length as an alias). input supports both integer seconds and ISO 8601 duration, but output is currently integer seconds, for the purely personal and subjective reason that ISO 8610 datetimes are fairly common but (in my wholly biased experience) ISO 8601 durations are much more rare, while integer seconds is fairly obvious and self explanatory. happy to switch if either the wild or standard converge on ISO 8601!

example: https://granary.io/url?input=html&output=rss&url=http%3A%2F%2Flatenighttoast.com%2F

[snarfed]

hmm, our examples of p-size in the wild are both human-readable strings, eg 62.2 MB, but that may not work. all other places we need size, notably RSS length, need the exact number of bytes, which we can't get from a human-readable approximation.

i could HEAD the audio or video file URL and use the Content-Length header, but that's overly heavyweight for a format conversion, and that header isn't even always available.

any thoughts on what to do here?

[snarfed]

discussed on #microformats. i'm tentatively going to start emitting a <data> element, so i can include both exact bytes and human-readable string, eg:

<data class="p-size" value="1234">1KB</data>

(i already handle both variants in input.)

[snarfed]

done. tentatively closing. feel free to reopen or add any other thoughts!