[vorbis] Re: PROPOSAL: Sub-Tagging

[Jonathan Walther]

On Sun, Dec 09, 2001 at 09:58:33AM +1100, Cameron Simpson wrote:
>The data are nonhierachical, but the tag categories arguables _are_.

I can't argue with that.  It's true.

>This is why I suggested recoding it with slashes - it moves the supposed
>hierachy out of the tag value, which remains nonhierachical as you remark,

Since Monty said subtagging is moot, it's a dead issue, but I'd like to
explain it from a coders point of view.

Have you ever used the getenv(), setenv() functions?  This is what the
tags are modelled after.  With single non-hierarchical tags its easy to
use gettag() for each of the 24 extant tags.  If you add hierarchy,
there is no way with the current API to "get all tags that start off
with ARTIST/".  So from a coders point of view, its easiest to keep the
24 tags flat.

I have heard the argument on IRC that "if we allow 24 tags, soon people
will require a jillion more, and who wants to support that?"

To those people I lay out a challenge:  find 20 more tags that meet the
stated goals of the standard, and are not synonyms for tags already in
the standard.  At that point I will admit the proposed standard is a
fool's errand and will pack it up and go home.  Until then, I am not
convinced.  I think the 24 tags in the standard cover every conceivable
case.

>and into the tag name, which is merely a string - the fact that it's
>got a slash in it has no effect upon the parsing code (which adhering
>to your own spec, allows all sorts of characters - including spaces,
>which I though odd - in tag names).

>The problem with singular words (especially MEDIA and ADDENDUM) is that

MEDIA is now SOURCEMEDIA, and ADDENDUM is now COMMENT.

>they require the reader to have the whole spec in his/her head. By adding

Not really. It boils down to how good the ripper and tag editor programs
are at presenting possible tags for users to use.

>Just did. I agree that stuffing "VALUE=x" inside the tag _value_ is
>asking for trouble - it's visually more noisy and certainly requires
>parsing code to be written for what used to be flat scalars. So shift
>it sideways into the tag name - no new parsing needed at all.

Even if you shift it sideways into the tag name, and if functions like
getnexttag() were available, it would still involve extra parsing code.
I think the people crying for "hierarchy!" are considering using that
hierarchy for a whole bunch (the jillion) of tags that aren't covered in
the standard.

I don't object to the desire for hierarchy, or to put a lot of extra
sideband information in the oggfile, but discussion on IRC has revealed
that the metadata stream is what is supposed to be used for "complete"
information about a track.  There may even be a place for xml in this
metadata part of an ogg file.  But the tags aren't it.  There is not yet
a standard for the format of the metadata stream, or for what should go
in it.  Perhaps you could start that discussion?  I appreciate the tag
standard I am proposing is more limited than you would like, but use of
metadata should fill your need.

Btw Cameron, thank you for understanding what I have been saying, and
representing my position accurately.  It was like a bucket of cool water
to a man being burnt to a crisp. :-)

Jonathan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: part
Type: application/pgp-signature
Size: 797 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/vorbis/attachments/20011208/1d895e84/part.pgp