[uf-new] hAudio ITEM/TRACK debate resolution
scott at makedatamakesense.com
Sun Oct 21 11:20:20 PDT 2007
On Oct 21, 2007, at 10:54 AM, Brian Suda wrote:
> --- i agree with these two points, but what i disagree with this the
> design of this "container" so far i have heard it called a container
> about tracks and albums and i have heard it called "track" by default.
You may have heard that, but I believe no one said it. I said hAudio
is considered a track by default, but I did not say that hAudio
*containers* are tracks by default. hAudio containers are by
definition not tracks, they're not the default, and anything specific
to tracks does not apply to them. But most of hAudio is not specific
to tracks, it's generally applicable to all audio.
> --- (we have lost the original HTML example in all the replies) If we
> are using a unique property for the string that is the ALBUM name
> class="album" then it is redundany to have BOTH class="fn album"
FN does *not* mean album name. It means *audio* name. Whether or
not that's the same as the album name determines whether or not we're
talking about an album. To paraphrase directly from the hCard spec:
If the "FN" and "ALBUM" properties have the exact same value
(typically because they are set on the same element, e.g. class="fn
album"), then the hAudio represents audio information for an album,
and should be treated as such.
> should be used for 1 or the other for the name of the string, be it
> the string for the album name, or the string for the track name. Since
> tracks seems to me more common, class="fn" for track names... and
> class="albums" for album names, not class="fn" for tracks and
> class="fn album" for album names.
This would be a redefinition of either FN or HAUDIO. Per the wiki
, FN is "The name of the object." The object here is hAudio,
which means *audio*, not track, and not album.
> The reason you think you NEED class="fn album" is because of your
False. It's because the *meaning* of FN and ALBUM are not the same.
They may at times refer to the same content, but that doesn't make
them mean the same thing any more than FN and ORG mean the same thing
merely because they often co-exist.
> If you have ONLY one way to represent the hAudio
> structure (which you don't there are several) then you do not need
Real world examples demonstrate multiple ways of representing audio.
> //haudio/fn == album name
> //haudio/item/fn == track name
That only works if we redefine HAUDIO to mean *album*.
> But instead haudio is attempting
> //haudio == track name
False. HAUDIO means *audio*, not track. You're treating a proposed
syntax optimization as a new semantic structure, which is a mistake
of yours, not a fault of the model.
> //haudio/fn == track name
False. HAUDIO means *audio*, not track, so FN here means "audio
name." Calling that a "track name" may work in imprecise discussion,
but we should be more precise here.
> //haudio/album+fn == album name (i don't understand this, it could
> just be //haudio//album)
False. ALBUM means "album title." FN (in HAUDIO) means "audio
title." That those two may in some cases overlap does not give them
the sort of shared meaning you've suggested here, which would be
completely at odds with the semantics of HTML's class attribute.
> But for now, if we impose a SINGLE structure to mark-up haudio (which
> i think is best, it helps adoption, examples and explaining) then we
> don't even need ALBUM.
The real world examples suggest otherwise.
> --- then this is two different things. With hAtom we solved the atom
> ENTRY, then put it in a FEED.
That made sense in hAtom. It does not make sense here, because
unlike feeds, audio has the same structure as both container or
contained. The publishing examples make this clear, and I think it
would help if you looked more at those and questioned a few of your
assumptions where they contradict the examples.
> If we have solved the atomic RECORDING,
> then we are putting it into a COLLECTION (or ALBUM) this is a level
> above hAudio.
False. A collection of audio recordings is itself an audio
recording. This is the implied schema derived from the examples.
You appear to be imposing your own assumed schema on this without
regard to the examples. That's not how the microformats process works.
> the concept of NESTING isn't new, hAtom does this.
> What is new and bad is nesting the same property inside itself.
False. Again, hCard does that. That doesn't make sense in general,
but it *does* make sense for audio. You've only criticized it in
contexts that have nothing to do with audio, and are thus irrelevant
to the proposal. Do you disagree with the specific assertion that
audio is made up of smaller segments of audio?
> if this is the ATOMIC structure for a Audio Object, then
> we need a class ABOVE haudio to contain multiple hAudios, much the
> same way hEntry is contained within an hFeed.
Correct. But it turns out this container is itself audio, so we can
re-use hAudio here. It seems to me you've assumed based on your
previous experience in other unrelated contexts that a container
could *never* be the same type as the contained items. I believe
this assumption is false, specifically in the context of audio, and I
challenge you to back up your assumption with some sort of rationale
rather than just repeatedly stating it as if it were fact.
>>> <!-- what is this? an album with a duration, or an un-named track in
>>> an album with a track duration? -->
>>> <div class="haudio">
>>> <span class="item">
>>> <span class="album">Album 123</span>
>>> <abbr class="duration" title="PT30M24S">30:24</abbr>
>> That is incorrect markup. The parser would identify that as an album
>> called "Album 123" with a duration of 30 minutes and 24 seconds.
> --- how is that incorrect? what if that is exactly what i wanted?
If you don't even know what it means, how could it possibly be
exactly what you wanted? It is not the microformats process to start
with markup and then try to figure out what it means. We start with
publishing examples, and figure out how to structure them most easily
> hAudio is about tracks and Albums correct?
False. hAudio is about audio.
> --- no, i agree completely that hAudio is a SINGLE audio recording. My
> issue is mainly with your original example which no longer models
> hAudio as a SINGLE audio recording:
> Album with two tracks, more detailed:
That an album is not a single audio recording is your *opinion*, not
a fact. The examples have suggested this opinion is wrong.
> Which brings us back to the my more verbose default TRACK of:
> <span class="haudio">
> <span class="item">
> <span class="fn">Hokkaido Dream</span>
> This (for now until we discuss optimizations) is how you would need to
> write JUST a track.
For now we're using a schema that everyone agreed to before you
entered the discussion. You're welcome to try to question that
schema and explain why you think a different schema would be better,
based on real world examples. But you can't just declare a different
schema. That's not how the microformats process works.
More information about the microformats-new