[uf-new] hAudio/table incompatibility

[Manu Sporny]

Julian Stahnke wrote:
>> 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 is a rule that we could certainly enforce via the parser... and it
would reduce the markup that a publisher would have to do.

Just to add a bit of implementation detail to your proposal:

An hAudio parser would then assume that the contents of TRACK is an
hAudio object if it is inside of an hAudio container. This means that
any uF markup inside of TRACK could be any of the properties of hAudio.

hAudio parsers, when seeing TRACK would create another hAudio object and
stuff the properties found in TRACK into the newly created hAudio object
for the TRACK.

Scott Reynen wrote:
>> What does ‘track’ mean in the context of the hVideo format, though?
> I think we're getting distracted here.  That's a good question for the
> hVideo discussion, but it's really irrelevant to the hAudio
> discussion.

I was attempting to think ahead to hVideo, but it seems to be causing
more confusion than helping. Scott's right... we should concentrate on
hAudio.

> Okay. If that’s the case, then I don’t see why ‘track’ could not be
> just plain text?

We could easily give publishers both options without complicating the
parser that greatly. Both of the examples below would be proper uses of
hAudio:

<div class="haudio">
    <h3 class="album">my album title</h3>
    by <strong class="contributor">the artist</strong>
    <ol>
        <li class="track">my track title</li>
        <li class="track">my track title</li>
        <li class="track">my track title</li>
    </ol>
</div>

<div class="haudio">
    <h3 class="album">3 live bands at my local venue</h3>
    by <strong class="contributor">various artists</strong>
    <ol>
        <li class="track">
           <span class="recording">first track title</a> by
           <span class="contributor">first artist</span>
        </li>
        <li class="track">
           <span class="recording">second track title</a> by
           <span class="contributor">second artist</span>
        </li>
        <li class="track">
           <span class="recording">third track title</a> by
           <span class="contributor">third artist</span>
        </li>
    </ol>
</div>

> Even though the tracks aren’t marked up as hAudio element and hence
> have no ‘position’ attribute, should ‘position’ be implied by the
> position of the track in the <ol>?

My thoughts are that it should be... but with the ability to override
the <li> numbering scheme. What happens if somebody only wants to list 3
of the items in the album... song 3, 5, and 8?

It should also be noted that the POSITION and DESCRIPTION concepts are
disputed additions to the proposal. I still need to go back through and
re-analyze the examples to prove that there is enough evidence in the
examples to add POSITION and DESCRIPTION to hAudio.

PODCAST is disputed by Martin and since I'm the only person that is
backing it based on the examples, it will probably be dropped unless
somebody else wants to see the ability to mark up PODCASTs via hAudio.
It also seems that RECORDING (was audio-title) is a disputed name
change, per Martin.

-- manu