[uf-new] hAudio ITEM/TRACK debate resolution

[Brian Suda]

On 10/21/07, Manu Sporny <msporny at digitalbazaar.com> wrote:
> FN is the formatted name of the audio recording.

--- that"s fine. I agree.

> Here are the rules we defined earlier this month, which have been
> updated to match the discussions over the past two weeks:
> ...
> # 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.

--- this is fine. I know why we have stated this. It is to prevent
something like
//haudio/item/duration being applied to just the //haudio/duration or
//haudio/item/fn mixing with //haudio/fn

I agree with this, no issues here.

> > 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.

--- ok, this is i think were i need to go back and read some things. I
don't disagree here, but think that there must be a better way to
represent this rather than infinite nesting of haudios. Then you could
re-declare the album to be different with each instance. Like i said,
i'll try to go back and see why this is.

> 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.

--- i don't disagree with anything but the infinite nesting of haudio
items. There have been alot of different people answering the same
questions differently. Thanks for your patience. Things are much
clearer and now that we agree on the basics and aren't "talking past"
each other, we can try to work out what is left.

-brian

-- 
brian suda
http://suda.co.uk