[vorbis] xml stream formats

[Michael Smith]

At 07:36 AM 7/9/00 -0700, you wrote:
>> metadata, but we aren't doing ANY of the stuff that XML is actually useful
>> for.
>
>What what stuff would that be, out of curiosity?

XML is a markup language. Anything where it's primarily being used to tag
sections of text in some way is something where XML is probably very
useful. Where the tags themselves are the majority of the content (which
seems to be the case here), it's not so useful.

Further, there is a VERY powerful API (DOM) that's widely used, and
available through a number of different parsers, for manipulating and
reading XML. We would have no use for DOM, basically, since the XML
'documents' would individually be very simplistic. 

>
>> The more I think about this, the more I see XML as a 'buzzword solution'
>> that doesn't really do what we want to do. Sure, we can force it into being
>> usable for our purposes, but it isn't a natural fit. I may well be missing
>> something, and I'd certainly appreciate having any such things pointed out.
>
>At least my own idea of this topic would be to have XML docs as a small
>part of the metadata stream.  You send a timecode, and a length, and
>then all the information is in a complete XML doc that defines the
>event.  Or is this where you're saying we're losing the usefulness?  A
>binary format is possible too I guess, I just figured XML is easier to
>generate and hack with...

You'd send all the data (including the timecode) as part of the XML
document. A length you might or might not put in the stream, depending on
specific needs (the end of an XML document is clearly defined). XML is
losing usefulness here because we're encoding a whole lot of raw data - but
then bringing in a complex parser to interpret it. 

For what the metadata stream would likely include, there wouldn't be any
complex markup in all, or almost all, cases. It'd just be <sometag>
contents </sometag>, perhaps with an attribute or two. All we really NEED
is stuff like "TIMECODE|LYRIC|some text" (either binary encoded or in some
sort of text form). XML might (depending on the exact form) be easier to
generate, but it isn't going to be easier to parse and use, even given a
pre-built parser. For our specific needs, XML just makes things more
complex in most cases.

Responding to another comment in a different mail - I agree, the fact that
we couldn't fit an XML parser into the winamp plugin isn't neccesarily a
problem, since we don't really NEED the info from the metadata stream
there. It's just something extra to consider.

I'm beginning to be convinced (from a couple of IRC conversations) that
there might be a need for some more complex metadata (well, data - at the
complexity we're talking about, it's more than just metadata), and there
XML makes a lot more sense. I'm not sure about this though, and I'm not
sure whether it's a good idea to have the complexity of XML for the simpler
cases as well. 

So, think about XML, and think about other things too - pick it if really
IS the best suited thing to what we want to do, but if it isn't, don't use
it just because it's a cool buzzword.

Sorry about this rather rambling message, I was sort of thinking as I went.

Michael

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