[uf-new] hAudio ITEM/TRACK debate resolution

[Manu Sporny]

Brian Suda wrote:
> I would
> also press for requiring ATLEAST an FN or ALBUM, not <span
> class="haudio">A string</span>. We can discuss this in a later
> itteration as an optimization.

That's fine... we can avoid talking about that for now since it will
simplify the discussion. I recognize it as an optimization in your
model. It is not an optimization in the "item haudio" approach, but
we'll get there eventually.

The main reason that was in there was to ease the burden on publishers.

>> If somebody wants to be even more specific and mark up an audio
>> recording that is a part of an album, they can do this:
>>
>>    <div class="haudio">
>>       <span class="fn">A Sound Recording</span> found in
>>       <span class="album">An Audio Album</span>
>>    </div>
> 
> --- yes, that is fine. FN could be your display-name in something like
> Operator, but Album is the name of the title of the album. If you
> WANTED these could be the same class="fn album", but to me that
> doesn't make any semantic compound. Just that the display name happens
> to be the same string as the album.

Just to be crystal clear, I think we agree... with one clarification. FN
is not "display name", FN is the "formatted name" of the audio
recording. "fn album" doesn't make a semantic compound, I don't think
anybody was saying that it did. Let's not say "display name" as it will
lead to confusion.

FN is the formatted name of the audio recording.

Here are the rules we defined earlier this month, which have been
updated to match the discussions over the past two weeks:

# If only FN is specified, then the hAudio is a general audio recording.
# If only ALBUM is specified, then the hAudio is an album.
# If both ALBUM and FN is specified, then the hAudio is a song/track
that is part of an album.
# If ALBUM and one or more ITEMs are specified, the hAudio is an album
containing tracks. Each track is assumed to be an hAudio, unless
specified otherwise. None of the track properties should implicitly be
added to the containing hAudio. In other words, the parser shouldn't
parse the contents of the ITEM hAudio into the higher-level, non-track
hAudio object.

> But as i understand, the ITEM could recursively be more audio-objects.

Yes, in the "item haudio" proposal it can. It is assumed that item can
contain anything that hAudio can contain, including more items.

>>> But instead haudio is attempting
>>> //haudio == track name
>> We should probably stop using "track name" - it seems to be causing
>> confusion. Use "audio recording" instead. We aren't as specific as a
>> track using that markup.... all we know is that it is an audio
>> recording... we don't know if it is an album and we don't know if it is
>> a track, nor do we know if it is a podcast. We don't know anything other
>> than it is an audio recording.
> 
> --- i agree, i have been under the assumption that it would have been
> a TRACK name, but you are right it should be re-defined as just a
> "string" that describes the audio object, which is optional.

Again, to be crystal clear - FN or ALBUM is required, it is not
optional. If you can't name what you are talking about, you can't talk
about it. This is very specific to hAudio - people refer to audio
recordings by name... the examples prove that, thus it is not optional.

>>> //haudio/fn == track name
>> We still only know the name of the audio recording, nothing else. It is
>> definitely not a track at this point.
> 
> --- ok, i can agree with this. So we do NOT know this is a TRACK, just
> an audio object with a title of some sorts?

Yes, that is correct.

If you don't disagree with any of the statements above, please explain
why you believe nesting to be a bad design choice. It seems like that is
the big disagreement, here.

-- manu