Promoting ODF (OpenDocument Format),Rick Jelliffe - myths debunked?
I do not claim to be an XML expert and my experience in the standards process is admittedly limited. I definitely will not even try to dispute the fact that Mr Rick Jelliffe, a well known developer in the XML world with valuable contributions in creating and promoting open standards would be an authority on what would constitute a good standard.
However what is puzzling me is that some of the myths he attempts to debunk as reported in this article about his latest visit to Bangkok does not dispell any myths at all. In fact it reinforces some myths and misrepresented the facts.
The article from the Bangkok Post is available here: "Open standards advocate comes out in favour of Microsoft", and syndicated in ZDNet Asia here.
On Dates
To demonstrate why I think Mr Jelliffe may be mistaken, my previous commentary entitled "Malaysia's History is ill-formed" has some information on how the Microsoft Office Open XML (MSOOXML) specification handles the encoding of dates; the very same subject which he addresses.
Here are his quotes:
"he [Jelliffe] pointed out that Microsoft had started work on developing an XML data format back in Office 2000, work that predates some of the ODF work."
"He said that accusations that Open XML contradicts other ISO standards can be explained and are not significant. One case is that Open XML stores dates as numbers, as has been the case in Microsoft Office all along."
Now let us examine some of the comments he has made with regards to dates. He states that Open XML "stores dates as numbers, and has been the case all along." This is an interesting statement due to the fact that its not true.
Microsoft has been working on XML data formats back in 2000 and drummed up huge marketing publicity of this support in Microsoft Office 2003. The then new file format however obviously was not open and good enough. Subsequently they had to change that format just one release later (in 2007). And you would have thought that XML stood for eXtensible.
However the Microsoft Office 2003 XML format (MSO2003XML) did at least one thing right; they had the dates encoded not in a serialized "number" format but was in fact encoded in an ISO standard format (ISO 8601) which was gave the format these features:
- Human Readability ( i.e I should not need to refer to the specs to figure out what the number "means") and
- It did not have to carry the application level baggage (bugs) of
- leap year miscalculations ( where 1900 was mistaken as a leap year )
- pre-1900 limitations ( where historical dates are hashed "####" out ) nor
- 1900/1904 epoch confusions. ( where different platforms have different starting dates )
Here is my justification:
The XML code above was generated by Microsoft Office 2007 in the form of the Microsoft Office 2003 XML format.
This shows that MSO2003XML format encoded dates "the right way," (conforming to well known internationally accepted date encoding standards) while the latest format, MSOOXML takes a step backwards in terms of open standards by going back on their decision in adopting the obscure "serialized number" format.
So while it is true that Microsoft has been working on XML formats prior to the 2003 release of their productivity software, it is not true that the serial dates were used "all along," as asserted by Mr Jelliffe. They went back on their decision in adopting ISO 8601 date encoding to their obscure binary representation of serialised dates.
On Size and Speed
He then proceeds to spread more myths to the argument:
"ODF 1.10 has 760 pages. However, it refers to a lot of standards such as SVG, MathML, Open Formula, xlink, zip. These are not ISO standards, these are from the W3C. Once you add them, they are quite comparable in size," he said.
This is his and many Microsoft representative's justification in why MSOOXML was so large at 6000 pages and is no different to ODF and should therefore be ratified at ISO.
The argument put forward by the many (at least 14) National Bodies who spoke up against MSOOXML back in February 2007 was not because of the fact that MSOOXML is the largest proposed standard ever to be standardised at ISO. If fact many NBs responded positively to the comprehensive information. Some even claimed that this was still not complete, and requested for more information.
The issue was because MSOOXML is probably the largest proposed standard to be "Fast Tracked" through ISO. Many NBs queried why such a large specification should warrant a fast tracking.
There is a big difference between "Fast Tracking" and the regular submission of ISO standards. This becomes more apparent if your specification is 10 times the size of the average proposed standard!
Additionally, ODF was not ratified with SVG, MathML, XLink, Zip and other W3C standards all together at the same time. Instead the prior W3C standards were already well established and approved in their own right and in their own time with the relevant experts of their specific domains vetting it.
MSOOXML also incorporates proposed "standards" which failed in the marketplace and now is offered a "backdoor" to standardisation process by piggy backing this nebulous specification. (See VML vs SVG, and MathML vs Microsoft Office MathML)
So there is a myth being built that ODF and its constituent parts are just as large as MSOOXML, and therefore MSOOXML is OK. I for one would rather MSOOXML be even larger; to cater for unknown tags like "lineWrapLikeWord6" or a Macro specification. However what troubles me is that the special relationship between Ecma and ISO should be abused with the fast tracking of this large specification.
We must never mix these two issues up ("ODF size" and "Fast Tracking") to justify ISO ratification.
On "Full Fidelity Decoding" and Interoperability
The final issue I would like to address is this statement:
" if I wanted to make sure that all the data in the document opens up the same way, then I'd go for Open XML," he said."
If I wanted to make sure that all the billions of legacy documents to be opened up the same way with full fidelity, then I would go for the current binary and proprietary closed file format by Microsoft. There is and always has been a worldwide demand for these file formats to be opened up for easy decoding. In fact if Microsoft really practiced interoperability as they so often preach, they should open up this specification freely, and we probably would not have any need of this discussion today.
Their proposed "solution" which is the mapping of the binary stream to XML in MSOOXML however is not the correct answer. This is a pseudo opening of the binary formats, where things are being left behind, left out and ignored. Why should the market go through another layer of abstraction just to get access to our binary documents? We are already seeing leaks in this abstraction with the difficulty in getting the Mac OS X port of the translators to work, and the exclusion of Macros to yet another file format for users to get confused by.
So our ideal request here is to release the binary information required to access our billions of user data created in Word, Excel and PowerPoint. Once we have that, then we can decide on what futuristic XML file format to base on.
Microsoft is attempting to roll these two separate issues (the decoding problem and future encoding format) into the supposed "magic bullet" called MSOOXML.
And once we solve the problem of the decoding of our data ( a problem only solvable by the vendor ), I and many National Bodies worldwide wholeheartedly agree with the illustrious Mr Rick Jelliffe:
"If you want something for interchange and if it is platform neutral, then I'd tend to ODF."
yk.
Jeffrey said "OOXML was never created with reuse of standards but with preserving compatibility with existing office binary documents which requires support current MS office functionality"
Not true. The chart drawing engine is rewritten and does not respect older charts. Many properties are lost. And in addition, the rendering is different (scaling, aliasing, ...), which is unexpected when you open an existing file for instance.
Posted by: Stephane Rodriguez | Thursday, 21 June 2007 at 03:58 AM
Jeffrey said "That seems you distorting the the truth by a mile. VML is added as deprecated for support of converted MS Office XML 2003 formats. That means it is for backwards compativility and not for rushing it troughas a standared."
It seems it's you who are distording the facts, or the specs is simply wrong.
If you think VML is deprecate, then please follow those steps : create a new Excel 2007 spreadsheet ; right-click on a cell and choose "Insert comment" ; type a comment ; save the spreadsheet ; close it.
Now unzip it. What do you see? A nice VML part.
There you go with your deprecate part.
Posted by: Stephane Rodriguez | Thursday, 21 June 2007 at 03:52 AM
yk said "If I wanted to make sure that all the billions of legacy documents to be opened up the same way with full fidelity, then I would go for the current binary and proprietary closed file format by Microsoft."
You are absolutely right, the best way to ensure longevity to your Office files right now is to save them as 97-2003 formats.
As to Mr Jeliffe himself, I am not sure what to think. I haven't read much of what he said since he seems paid for in whatever he said, but I am curious to know how much of the specs he has implemented in order to come up with positive backing as he does.
I implement the specs, and the more I implement it, the more negative I am about it.
You said OOXML is 6,000 pages. But that's just the syntax! If you add all the semantics, none of which is documented (i.e. what attributes really mean, how they combine together, and so on), then you are talking more about a monster 600,000 pages.
That is a reflection on the length of the actual MS Office implementations themselves. As Rob Weir said elewhere, the new OOXML file formats are really the DNA of the applications, which means it's proprietary.
Posted by: Stephane Rodriguez | Thursday, 21 June 2007 at 03:48 AM
"That sounds like the groklaw defintion book of contradictions. That is like stating that a hexadecimal counting system contradict an octaganol counting system."
If your standard expect octal numbers, and another standard delivers hexadecimal numbers, this is called an incompatibility. However, OOXML uses an idiosyncratic hexadecimal counting system for numbering languages, countries, and colors, whereas ODF uses the ISO ASCII general names. OOXML here breaks a widely used international standard for no other reason than that they are too lazy or incompetent to do the internal conversion before they write out the data.
That really is called "incompatible by design".
Witner
Posted by: Winter | Wednesday, 20 June 2007 at 06:42 PM
"[quote]The ODF team talked to everyone who wanted to participate and together they compiled the best standard they could. They based every aspect of ODF on existing standards where possible.[/quote]
The ODF team could easily be called the Sun/OOo and friend team and they did not talk to anyone but just send out a message that they were going to make an interoperable format for OpenOffice based on the OOo formats. Why would MS even be interested in participating in a format ment for use in a competing product."
Because MS were part of Oasis. And the design team included, among others, SIL, the bible translation people. If there is something to know about languages, writing systems, and XML, they know it.
The ODF design team included all the people you would love to include designing a document format, except MS. MS simply refused to participate, although I understood that they DID sit in and listen at EVERY Oasis meeting.
Limiting ODF to Sun/OO.o is a way for MS to dismiss those public interests it wants to hurt badly. Isn't it?
Winter
Posted by: Winter | Wednesday, 20 June 2007 at 06:38 PM
[quote]This proposed OOXML "standard" contradicts every W3C standard, including those that ensure sane XML. It even contradicts some ISO standards.[/quote]
That sounds like the groklaw defintion book of contradictions. That is like stating that a hexadecimal counting system contradict an octaganol counting system. In the real world people call that compatible formats. OOXML is compatible to MathML for instance so MathML can easily be converted to OOXML. MathML is only limited compatible the other way around but that is due OOXML being a lot more extensive. That however is not a contradiction but an extension of functionality.
[quote]The ODF team talked to everyone who wanted to participate and together they compiled the best standard they could. They based every aspect of ODF on existing standards where possible.[/quote]The ODF team could easily be called the Sun/OOo and friend teamand they did not talk to anyone but just send out a message that they were going to make an interoperable format for OpenOffice based on the OOo formats. Why would MS even be interested in participating in a format ment for use in a competing product.
And in basing thing on standards it seems ODf in general overlooked most ISO standards but in stead chose for W3C standards which are mostly created with webdocuments in mind and a lot less with Office documents. As webdocuments are in general much more limited than Office documents using mostly webstandards would always pose a risk of reduced functionality compared to current Office suite requirements.
(p.s. Thanks for the discussion but I cannot spent anymore time here !!)
Posted by: Jeffrey | Wednesday, 20 June 2007 at 04:55 PM
This all starts to sound like "He had a cookie now I must have one too". No one has a right to their own private international ISO standard.
"If W3C or OASIS did not like ISO 12083 why did they not try to improve that ISO standard or extend it for use in ODF but use another format in stead ?"
Quite simple, ISO 12083 is not XML. It requires SGML interpreters that just don't exist. Converting it to XML would have been pointless. What the ODF committee did was use existing XML standards that are in widespread use and adapted these for use in ODF. What MS did, was to dump their internal memory structures and wrap it into XML (see Bill Hilf's remarks).
But you are missing the whole point. The ODF team talked to everyone who wanted to participate and together they compiled the best standard they could. They based every aspect of ODF on existing standards where possible.
Did you hear the W3C complain that their standards were extended? No, because everyone there had their say in the new standard.
In no way can you, nor MS, claim that ODF was constructed to exclude anyone, or break any existing application. Everyone who wanted could have their say, and the standard has been changed and extended to get as many people on board and happy as possible.
Compare OOXML. No one was allowed to even SEE it until it was dumped upon ECMA. ECMA did not invite comments, it didn't even publish their minutes. Then the ISO JTC got 30 days to decide on 6000 pages of OOXML specification. Which were repaginated at random moments.
This proposed OOXML "standard" contradicts every W3C standard, including those that ensure sane XML. It even contradicts some ISO standards.
Why should anyone give MS their international multiplatform multivendor ISO standard when their is not a single reference implementation (as far as I know even Office 2007 is not certified or checked for compliance).
Even MS considers OOXML inadequate for documents as Office 2007 prefers other formats to save to.
"So ODF does not just support SVG graphic elements but also support propriety (openoffice related) draw and draw3d elements."
Nothing in OO.o is proprietary, it is GPL. ODF is free and open too. And MS is welcome to use them. You seem to argue that if ODF adapts existing standards, that were not designed for documents, in well documented manners, MS can just scrap every standard in existence? Even Rick Jelliffe argues that ODF can be so much more concise because it builds on existing standards (in itself a rather insincere support for OOXMLs 6000 pages).
"So if MathML does not suit Office functionality currently already in use by 90% of the world they should still use that "
See:
/2007/02/billions_of_doc.html
First, MathML is only used in SOME versions of MS Office. This does not comprise 90% of all documents. Of all the incompatible Office applications, MS Office conflicts most between versions. Furthermore, many scientific journals have banned OOXML because it's MathML is incompatible with the earlier versions.
"OOXML was never created with reuse of standards but with preserving compatibility with existing office binary documents which requires support current MS office functionality"
OOXML is in no way compatible with earlier MS Office formats. Earlier versions of MS Office nor OpenOffice can read OOXML. And these earlier documents cannot be easily converted to OOXML, except by reading them into Office2007. You cannot incorporate .doc in OOXML nor vice versa.
The best converter from legacy MS formats to XML (ie ODF), btw, is the Acme376 plugin, if MS allows you to run it. It has a 100% round trip reliability. Much more than OOXML.
Winter
Posted by: Winter | Tuesday, 19 June 2007 at 10:14 PM
If W3C or OASIS did not like ISO 12083 why did they not try to improve that ISO standard or extend it for use in ODF but use another format in stead ?
MS does not think MathML has the required functionality so why not use another format then ??
It seems logical to ODF to use other formats but when MS does it is isn't.
And for the SVG. As I remember it correctly ODf supports 3 types of graphic elements draw element, 3d elements and svg elements that can combine for graphics use within ODF. You cannot copy the draw and 3d elements to svg documents however. So native graphic elements in ODF are not full SVG but SVG DRAW DRAW3d. So ODF does not just support SVG graphic elements but also support propriety (openoffice related) draw and draw3d elements.
[quote]If MS Math markup doesn't suit the world, bad luck for the world[/quote]So if MathML does not suit Office functionality currently already in use by 90% of the world they should still use that ???? Or they should go back to the level of functionality provided by ODF format users ???
Why has ODF used those propriety draw features in ODF. That was so as not to loose draw and 3d draw functionality already present in OpenOffice. They did not want to use just SVG as that is a regression to current functionality. Same for Microsoft that provide more functionality than any Office suite. They require formats that support that functionality and not just formats that are readily available.
OOXML was never created with reuse of standards but with preserving compatibility with existing office binary documents which requires support current MS office functionality
Posted by: Jeffrey | Tuesday, 19 June 2007 at 08:47 PM
The ISO 12083 argument is positively disengenious, as this is NOT XML. So using it would break the XML in ODF. Moreover, it is a book publishing standard, with some Math in it. See here
http://www.press.umich.edu/jep/03-04/hicks.html
It seems the standard was not much used.
The W3C standard is valid and sane XML, and widely used.
"This is exactly one of the reasons why it is actually good to have Micrsoft using standards that are different. Because of the openness it means there is always the ability to convert compatible parts but it also means that Microsoft cannot tamper with standards used by others and introducing propriety extentions to those standards"
Your arguments are puzzeling. First, no-one has a say in the evolution of the OOXML sub-standards. If MS Math markup doesn't suit the world, bad luck for the world, they cannot extend or change anything in it. (I still do not know whether it is even legal to implement a changed version of OOXML) And there are no compatible parts in OOXML. It is all MS only.
Second, you say it is bad to define an open, new standard by extending a previous standard. But it is actually GOOD to duplicate the functionality of an existing subset of an ISO standard (SVG/Math inside ODF) by a completely new and incompatible subset in another ISO standard. All those with a stake in the original W3C standards actually agreed with the ODF extensions, if I remember well. MS never even asked other users of the relevant markup languages if they wanted them.
Your "two standards are good" argument sounds like the argument about which side of the road you can drive best. MS (and you?) suggest "lets try both simultaneously and see which side will win".
I thought the disaster from the mobile phone standards war in the US showed that competing standards are horribly expensive. The EU has reaped really massive economical benefits from standardizing on GSM. I think the same disaster will happen if all document standards are duplicated.
(and Jeffrey, maybe you can help me out. Is it really true that standard Dublin Core applications cannot be used on all OOXML documents? I can't find the information)
Winter
Posted by: Winter | Tuesday, 19 June 2007 at 04:40 PM
Jeffrey,
> > there is no ISO certified
> > Math markup language
> I think ISO 12083 is.
You are right. However if you trace the history of ISO 12083, it is patchy at best. Unused at worst.
http://www.mathmlcentral.com/history.html
http://www.w3.org/Math/mathml-faq.html
So OASIS had to choose between MathML and ISO 12083. But notice that they didnt create a standard of their own.
The issue at hand here, if you remember is how MSOML is piggy-backing MSOOXML to become yet another math markup language.
BTW, if ISO 12083 was so good, why didnt Microsoft adopt it?
> you can't just copy ODF SVG markup to
> SVG files as that would require a converter.
Really? Care to elaborate?
===
Your rant about Microsoft's Embrace, Extend and Extinguish (EEE) and how people are sceptical of Microsoft's intentions is humourous, but not relevant.
If Microsoft's intentions are clear in embracing and extending existing standards with consensus from all parties, then there will be very little resistance to these efforts.
[Microsoft's track record however works against them, which is a pity]
So if Microsoft just sticks to the first two Es, there would be no problem.
However submitting a whole new standard for each and every domain is jumping the gun to the last E (Extinguish).
Additionally, lets not get too hypothetical about what Microsoft would do, or how the community would react here.
If Microsoft truly supports ODF tomorrow, by implementing true native default file save as features to a high fidelity, I for one would be extremely happy.
If they extend the ODF schema via the OASIS TCs, contributing valuable input, I too would be happy.
I however, would not be happy if they immediately extended ODF without the ratification of OASIS, and only allowing (technically or legally) the new features in their own products. This is the evil version of Extend which the community should be aware of.
> it also means that Microsoft cannot tamper
> with standards used by others and introducing
> propriety extentions to those standards
... Which is already happening to MSOOXML today. MSOOXML is different to MSOOXML with Macros (MSOOXML M).
As I said earlier, nailing down the formats is easy be it binary or XML. If Microsoft cares so much about its user's data and interoperability, it just needs to publish all the binary and proprietary file formats it has ever created and users used.
Then we can decide which XML or binary or what-have-you format to use ...
yk.
Posted by: Yoon Kit | Tuesday, 19 June 2007 at 04:30 PM
[quote]BTW, there is no ISO certified Math markup language[/quote]
I think ISO 12083 is. MathML is not based on that nor does it reuse it's syntax or structure.
[quote]Is it easier to add the "mutations" feature to MathML or define a brand new language?[/quote]
So if Microsoft walked into W3C and proposed a whole lot of suggestions to MathML they would see them all back in MathML's next version ? No they wouldn't. Your suggestion effectivly means making a propriety extention to a public standard.
They could use the solution created by ODF for SVG. As SVG was inadequete for Openoffice needs ODF has selfcontructed propriety extentions to SVG in it's standard. This means ODF which you claim uses SVG standards actually uses SVG which is not exactly compatible with SVG. you can't just copy ODF SVG markup to SVG files as that would require a converter.
If Microsoft would have created their own extended version of MathML simular to ODF creating their own version of SVG there would have been a big uproar about Microsoft's EEE strategy on MathML. As it is you can fairly easily convert MathML to ooxml math and convert it back. On converting it back you could of course lose some office related info that cannot be stored in MathML.
I am surprised that you as OSS supporters of all people are even suggesting that Microsoft should just use mathML and extend it to fit their requirement while the whole of OSS is always adamant about Microsoft not extending standards.
I remember the issues and comments around extending html. If Microsoft were to have used extended versions of MathML and SVG or other W3C standards I think the protests would have gone trough the roof and I bet this blog would have been in the forefront of that protest.
This is exactly one of the reasons why it is actually good to have Micrsoft using standards that are different. Because of the openness it means there is always the ability to convert compatible parts but it also means that Microsoft cannot tamper with standards used by others and introducing propriety extentions to those standards
Posted by: Jeffrey | Tuesday, 19 June 2007 at 03:46 PM
"For their math format it is clear that the W3C MathML itself is not following the ISO standard or the most commenly used LaTex Math notation format and"
LaTeX is NOT an XML markup language. It is more like a programming language. I believe there is a XML rendering of LaTeX, but that would likely not fit in ANY Office XML.
"The math solution created by MS is also not a proposed standard but new functionality that does fit the requirements that were needed for the office functionaility."
MS' math solution is part of the OOXML standard and therefor not new functionality but a proposed international standard. MS still have never been able to tell the world why ALL W3C standards seem to be inadequate.
"We could however wonder why ODF can use the standard while Microsoft finds it inadaquete."
For the same reason MS OOXML doesn't use sane XML or date formats to begin with. MS OOXML is a description of Office07, warts and all. Open Malaysia already reported how Bill Hilf publically announced this fact.
Winter
Posted by: Winter | Tuesday, 19 June 2007 at 02:42 PM
> That seems you distorting the the truth by a mile.
Really?
1) VML failed against SVG at W3C back in 1998. (SVG is actually VML improved!)
2) Microsoft Office MathML (MSOML) is not supported as widely as W3C MathML. (MSOML is not even supported in older versions of Microsoft products)
3) These one-vendor standards are bundled in one giant specification.
4) This giant specification is being fast tracked to become an ISO standard.
So my statement:
"MSOOXML also incorporates proposed "standards" which failed in the marketplace and now is offered a "backdoor" to standardisation process by piggy backing this nebulous specification."
... is certainly not very far from the truth.
===
> VML is added as deprecated for support
> of converted MS Office XML 2003 formats.
This is exactly my point: legacy fidelity and a new file format are completely two separate issues.
If Microsoft wants to document the file formats of Word6, Office 95, 97, 2000, XP, 2003, then do that. Release the binary and proprietary information of VML, MSOML, etc.
But if the purpose of MSOOXML is for the future encoding of documents in XML, then legacy documents like VML (and all the other "weird-stuff") should NOT be in the spec.
BTW, there is no ISO certified Math markup language. The closest is the W3C standard in MathML, which ODF correctly chose. It looks like ODF was in good company, as MathML is also supported by Publicon, Mathematica, Mozilla, OpenOffice, KOffice, SciWriter and all other leading Mathematical software. Converters are available from LaTeX as well.
Why did Microsoft deem it necessary to create yet another mathematical markup language, which is incompatible with its own prior software?
Is it easier to add the "mutations" feature to MathML or define a brand new language? Which do you think helps customers? Which respects the standards building community? Which piggy-backs?
So, am I now 1 mile off or two miles off?
yk.
Posted by: Yoon Kit | Tuesday, 19 June 2007 at 12:25 PM
[quote]MSOOXML also incorporates proposed "standards" which failed in the marketplace and now is offered a "backdoor" to standardisation process by piggy backing this nebulous specification. (See VML vs SVG, and MathML vs Microsoft Office MathML) [/quote]
That seems you distorting the the truth by a mile. VML is added as deprecated for support of converted MS Office XML 2003 formats. That means it is for backwards compativility and not for rushing it troughas a standared. In fact it is even a clear statement from Micrsoft that they have given up that format altogether as even they should not use it in new OOXML documents anymore.
For their math format it is clear that the W3C MathML itself is not following the ISO standard or the most commenly used LaTex Math notation format and that MathML lacks certain capabilities (like keeping track of mutations within formula's) making it unfit for use in MS office. It seems realy more suited for webdocuments which in general do not need that functionality. The math solution created by MS is also not a proposed standard but new functionality that does fit the requirements that were needed for the office functionaility. We could however wonder why ODF can use the standard while Microsoft finds it inadaquete. Probalby this is due to timecontraints in ODF developement, wising to reuse W3C standards in stead of looking at ISO standards and a lack of people that were in the TC that have a large usergroup in Math documentation. To mathematicians creating documents the inclusion of MathML would not make a format a usefull substitute for LaTeX. Mayby the next generation of MathML could be an implrovement but at the moment that still not good enough and also still very much geared for relativly static webdocuments.
Posted by: Jeffrey | Monday, 18 June 2007 at 10:35 PM
Having discussed with Mr. Jelliffe some points about the quality or "technical merit" of OOXML ( ISO DIS 29500 ) via blog comments like this [1] ...
... well, i gave up ! : i don't get the logic he uses in his responses and he has 0% autocritic. Honestly, for me it's a waste of time to discuss with him and i don't post anymore ( i say this with my respect to his career and XML contributions ).
I believe that at USA's INCITS V1 are people that *really* cares [2] about XML, his roots, philosophy and goals ( like Jon Bosak [3], on of his "fathers" ), so i still have hope.
I don't see the point about this crazy rush to standarization, please calm down ! take out from fast-track this monster ( OPC, VML, DrawingML, redefinition of MathML with propietary Math XML, WordProcessingML, SpreadsheetML, PresentationML ), plagued with Windows and PC platform dependencies, super sized, multi part, multi standard, with deprecated and new specifications inter-mixed, with interoperability specifications missing, etc. etc. and ...
* honor the word "standard" *.
[1] http://www.oreillynet.com/xml/blog/2007/03/no_showstopping_contradictions_1.html#comment-545467
[2] http://www.ibiblio.org/bosak/v1mail/200705/2007May17-160039.eml
[3] http://en.wikipedia.org/wiki/Jon_Bosak
Posted by: omz | Monday, 18 June 2007 at 02:56 AM