“you might as well use a binary format. There isn’t any standardized form of binary format for this level of information. Else that would indeed be a lot more efficient.”

hAl, this is true, but if Office Open XML is standardized, then only in the sense of having an “ECMA standard” label attached to it. XML is standardized of course, but it’s not a format, it’s a meta-format. While XML nicely handles syntactical and some structural issues, it cannot cover semantical problems because it was never designed to. Auxiliary standards are necessary to achieve this, and by that I mean standards that actually try to satisfy the immediate needs of their users, and not the needs of isolated application maintainers who have to deal with legacy cruft like incorrect date handling for the year 1900. Developers matter, but in this case, instead of giving developers something that works well for most, here Microsoft is asking the majority of developers to bend over backwards so that a few guys at Microsoft itself have less worries. This is certainly not what I intended to express.

Also, what’s efficient is a question of criteria. Zipped ODF is a lot more space-efficient than binary MS Office files.

“Suggestion here that verbose tagging improves the programming surrounding the format I find mainly a sign of using poor programmers. Tags in a standard file are static data to a programmer. All tags are known beforehand and cannot change.”

hAl, are you kidding or where can I buy the stuff you seem to be smoking? Of course tags are irrelevant if all you are doing is dump data to and from XML in a single application. You could just as well enumerate them. But we are talking about a format whose stated purpose is interoperability between different applications, possibly even in different programming environments, where you cannot even re-use libraries easily if you had the source code. This means there are going to be two to many (given the baseless insults you sputter, I am however no longer sure whether you can count that far) implementations, probably written by many different people. This means a training effort that someone, anyone has to pay for, even if you might not, and obviously less effort per person saves actual hard-earned money. If you don’t care, then it’s either because you don’t care about money at all (I’ll be glad to give you my IBAN), or because it’s simply not yours. The latter would be called egocentrism.

“If people were actually creating odf documents using an ascii tekst editor and typing the tags together with the office data then verbose tagging would have a reasonable use.”

Really? Have you ever written an XSLT stylesheet? Sure, there may eventually be a reliable, efficient and cheap Java library, with a flexible license, an easy to use API, excellent documentation and a vibrating user community that is eager to provide support, which transparently handles OOXML documents. Also, there may be a Perl module, and a Ruby module and whatever. Just as there might have been such libraries which directly read and write MS Office binary formats, but which in the real world never materialized, because no one had both the ability and the inclination to tackle this beast. In an ideal world, such libraries will be growing on source trees. My predicition, however, is that lack of suitable libraries will again be a constraint that greatly reduces the de-facto interoperability of the new MS Office formats. While library support for ODF is at the present inadequate, too, lack of libraries is much less of a problem given a simple and self-explanatory format than given OOXML.

If it is proven that the verbose tags perform exactly the same an the non-verbose tags I would certainly not object to using them.
But claiming there is a need for verbose tagging should have some decent basis and I cannot find that when verbose tags are used in a standard.
If people were actually creating odf documents using an ascii tekst editor and typing the tags together with the office data then verbose tagging would have a reasonable use.

I think that with preservation and semantic content as 2 key goals of ODF, the benefits of XML oughtweigh the drawbacks. A standard is a great thing to have, yet ODF also uses human-readable XML because standards may be inconvenient or impossible to use far in the future. ODF is a totally free standard (ie it will last a long time), so we are doubly blessed.

(changed tags to ‘[' and ']‘ due to blog limitations)

Think of it this way. Searching through a 6,000 pages specification to find the meaning of an element name will take you how long? 30 seconds? 2 minutes? Keep in mind that short names make searching more difficult. Good luck searching the 6,000 page specification for the meaning of an element called “t”.

On the other hand, having a name that is self-describing will take you how long to interpret? 0.1 seconds? 0.5 seconds?

This doesn’t mean the names need to be long. But they should be long enough to mean something to the reader without having to search through a 6,000 page specification.

The fact that 99.9% of the interpretation is done by machines is irrelevant. The important fact is that 100% of the bugs are caused by humans, humans who are writing code under short schedules, pressure from their bosses and not enough time to test adequately. Using intuitive names in XML is for their benefit.

You should never through that away unless
1) Brevity is an issue
2) Technical limitations preclude it
Neither is the case with XML.

You want to make more work on yourself, fine, but don’t use XML. Since “no one will read it” anyway, you might as well use a binary format. The rest of the world recognizes the value of self-documenting data.

Ditto for things like the standard C library. The fact that it is a standard does not eliminate the need for choosing good names. Sure, I bet an C-compiler would be slightly faster if printf() was just called p() and fopen() called f(), but the gain is miniscule.

Here is the simple argument for choosing intelligability over compaction for things that developers need to work with on a daily basis: machines will get faster, storage will get cheaper, bandwidth will increase, latency will decrease. But developers are not going to get any smarter than they are today. So a trade-off that sacrifices comprehension for miniscule performance benefits is ususally the wrong decision.

Also, keep in mind that ODF, with longer, more descriptive names results in smaller sized documents which parse faster than the same document expressed as OOXML. Choosing smaller element names, as OOXML does, cannot make up for the fact that OOXML requires far more XML documents to describe the same document. That is where the time is spent, parsing many small XML files. It is sad that OOXML has ended up both slower, as well as more obscure. Not much of a trade-off, eh?

Having a humanly readable format is invaluable for debugging, testing, etc. It shortens the mental distance from the output to the interpretation of the output.

This is similar to the reason why choosing good variable names in a program leads to easier comprehension and maintenance, and hopefully higher quality and lower cost. Ditto for well designed functions, classes, modules, libraries, etc. We’ve acquired the wisdom over the years to realize the importance of well-designed and well-documented code libraries. Although the end-user does not see the code directly, the end user should care, because the quality, innovation and cost of the product they use is partially determined by the quality of the libraries it is built upon.

A well-designed XML language is very similar in this regard.

Because it is useless in an office fileformat. Anybody that is reading the file from the XML using only the tags as a describing guide should be locked up in an asylum.

In any case, I don’t believe that my meager talents would have been useful to any TC whose charter constrained them to producing a specification that preferentially advantages a single vendor to the exclusion of all others. That’s a “sweetheart deal” of a charter for Microsoft to have, and on principle I’d decline to participate.

Would it not have been a good idea for IBM to have joined TC45 and bring all these issues up before the spec reached a final stage?