If you are concerned about size, compress it. The Zip classes use a compression algorithm that assigns tokens to commonly occuring strings. The net result is compression of a database represented in XML tends to give incredible compression rates as it takes all of those long repeated tags and compresses them to small tokens.
I use zip compression for a database we transfer using XML, and regularly achieve 90%+ compression. One example is a 26M XML document that compresses to 933k. In fact, the compressed version of the XML takes less storage than the original database. You could also easily write a Filter to convert to and from your </> tag format. I think the idea of abbreviated end tags has some merit, and I can see cases where I would prefer it. "William H. Mitchell" wrote: > At 12:38 AM 2/22/03 -0700, Martin wrote: > > > >My guess is to help humans match the tags that may be pages apart. > > A good editor should be able to handle that. > > At 08:10 AM 2/22/03 -0700, Vincent wrote: > >I would assume it would make it easier for the parser to find problems like: > > > ><a>1<b>2<c>3</></> > > > >So a tag is missing, which one? ... > > One answer is that the document is not well-formed and there's no way to > determine what it should be. > > Another is that a </> tag would simply close the nearest unclosed element. > By that, it's the <a> that's not matched. > > Based on a few samples I've observed that element names in closing tags > typically amount to 10-30% of the text in an XML document that's a database > of some sort, like a catalog. That strikes me as a significant amount of > overhead, but that's of course good news for hardware manufacturers... :) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
