<div>I don't think that dependency is a problem, why? Because many (very) people are using .NET and J2EE platforms (the most), here you have xml support. Others problems we can solve.</div>  <div><BR><B><I>Scott Wheeler <wheeler@kde.org></I></B> wrote:</div>  <BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">On Friday 10 February 2006 23:32, Dan O'Neill wrote:<BR>> Anyone want to start a draft set of requirements for XML tags?<BR>>   - Backwards compatibility w/existing tags<BR>>   - Adoptable<BR>>   - Must have a reference implementation for writing and reading<BR>>   - ?<BR><BR>I didn't actually send the responce I typed to the XML tags bit because I <BR>didn't take it seriously, but well, since it seems that you're on that track:<BR><BR>There are many problems with using XML as a generalized tagging format. The <BR>largest three are (I'm not anti-XML; it certainly has many useful
 <BR>applications, but this is in my opinion clearly not one of them.):<BR><BR>- This would require implementers to include an XML parsing engine. For all <BR>of the complaints here about the complexity of ID3v2, XML is much harder to <BR>parse (but of course there are existing parsers, but then you face more <BR>external dependencies).<BR><BR>- XML is hierarchical rather than linear. All tagging formats that I know of <BR>can be parsed linearly treating the tag as a bitstream. Maintaining a DOM <BR>tree consumes not-insignificant amounts of memory and processing. While this <BR>would just be an annoyance on the desktop, currently my EUR 60 CD player can <BR>read ID3v2 and I assure you that it does not have an abundance of RAM. Also <BR>the overhead in processing speed becomes significant even on the desktop when <BR>you consider working with tens of thousands of files.<BR><BR>- XML is larger. This isn't a problem in terms of storage; you can write <BR>pretty huge tags before they're
 significant relative to the audio content -- <BR>but again, thinking deeper and of implementations is important. If you're <BR>indexing an MP3 collection you're likely trying to minimize disk access. If <BR>the average tag size went from 2 kb to 10 kb (I'd assume larger padding with <BR>XML tags), disk reads being the major bottleneck in music collection <BR>indexing, you're probably effectively making indexing 5x slower (Ok, probably <BR>a bit less than that since disk buffers are probably working on pages larger <BR>than a kilobyte, but you get the idea.).<BR><BR>Cheers,<BR><BR>-Scott<BR><BR>-- <BR>If the answer is "more lawyers" then the question shouldn't have been asked.<BR><BR>---------------------------------------------------------------------<BR>To unsubscribe, e-mail: id3v2-unsubscribe@id3.org<BR>For additional commands, e-mail: id3v2-help@id3.org<BR><BR></BLOCKQUOTE><BR><p>
                <hr size=1><font face="Arial" size="2"><a href="http://us.rd.yahoo.com/mail/uk/taglines/default/photos/*http://uk.photos.yahoo.com/"><b>Yahoo! Photos</b></a> – <font color="red">NEW</font>, now offering a <a href="http://us.rd.yahoo.com/mail/uk/taglines/default/photos/*http://uk.photos.yahoo.com/">quality print service</a> from just 8p a photo.</font>