[uf-new] hAudio/table incompatibility

Julian Stahnke julian at julianstahnke.com
Sat Oct 6 11:24:26 PDT 2007

> I'm guessing that you don't like the fact that you must define both
> 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>

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.

More information about the microformats-new mailing list