[vorbis] Re: PROPOSAL: Sub-Tagging

[Cameron Simpson]

On Sat, Dec 08, 2001 at 03:30:25PM -0800, Jonathan Walther <krooger at debian.org> wrote:
| 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?

Yes. Even written my own implementations for systems without them.

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

Feh. Add a single getpfxtag() function and you're laughing. Supposing the
internal storage to be an array of char*:

        static char **tags;

        static int
        haspfx(char *tag, char *pfx)
        { return strnacmp(tag,pfx,strlen(pfx)) == 0;
        }

        char **
        getpfxtag(char *pfx)
        {
          char **matches;
          int nmatches=0;
          int i,j;

          for (i=0; tags[i]; i++)
          { if (haspfx(tags[i],pfx))
              nmatches++;
          }

          matches=(char **)malloc(sizeof(char *) * (nmatches+1));
          if (!matches)
            /* let caller deal with out of memory */
            return matches;

          for (i=0, j=0; tags[i]; i++)
          { if (haspfx(tags[i],pfx))
              matches[j++]=tags[i];
          }

          matches[j]=(char *)NULL;

          return matches;
        }

There. 2 minutes' coding effort.

| 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?"

This is why hierachical tag names are a win. With getpfxtag() the app can ask
for all the weirdo ARTIST variants in one fell swoop. Likewise the other tags.
It neatly accomodates weirdo names hitherto unthought of.

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

Oh, I think they cover damn near everything, but "every conceivable"?
Let's get real here :-)

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

Thanks.

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

To an extent - in which case why argue over the tag names at all? But
since we _are_ considering the names themselves we may as well try to
make them fairly self explainatory.

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

Yes, but not much.

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

At least it would put the made up new names in a more cohesive arrangement.

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

Well sure.

So, how limited in scope are tags meant to be then?

| There may even be a place for xml in this
| metadata part of an ogg file.

I'd be for that. XML is VERY easy to parse if you don't have to build in a
real DTD parser, and flexible.

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

Oh, I'm a catalogue fetishist too.

--
Cameron Simpson, DoD#743        cs at zip.com.au    http://www.zip.com.au/~cs/

A Newbie: I was not asking the question to start any flames. [...] Nobody
    has to get to the low levels of argument and be rude to each other.
Paul Tsai <pault at hurricane.seas.ucla.edu>:
    Oh yes we do, grasshopper.  It's a requisite for rec.moto.  One must
    transcend the infinity of illussions before getting the real techno whiz
    answers to questions of such profundity as yours.
John Stafford <stafford at ultra1.Winona.MSUS.edu>:
    No, he's right. After reading r.m. for a couple of years, I feel capable
    of being rude to ANYONE at ANY level of argument. In fact the higher they
    come, the harder they fall.....

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.