Reuse of existing standards

In looking through some of the work Ecma has done to identify in a clear way how existing standards are leveraged, I found the blog post from Jesper Lund Stocholm about the use of SVG within ODF to be very interesting. This is an example of how difficult it can be to get cross-application interoperability when you have a specification that is vague. I think this is an obvious area where things could be improved (both in terms of the spec, as well as the implementations who try to follow the spec).

For those of you interested in the technical details, it is a great read. Also some good discussion down in the comments:

January 20. 2008 20:59

In the ODF schema, there are 9 elements in the SVG-compatible
namespace. They are as follows:

svg:radialGradient, and

Where are the basic primitives of SVG such as rect, circle, ellipse, line, polyline, and polygon? They do not exist in
the SVG-compatible namespace. Something similar to them
appear in the draw namespace, which is specific to ODF.


January 21. 2008 03:08

Anon, thanks for your reply,

Where are the basic primitives of SVG such as rect, circle, ellipse, line, polyline, and polygon? They do not exist in
the SVG-compatible namespace.

Yes - well that really emphasizes my point. ODF both augments and limits SVG and vector graphics are, at the end of the day, not handled by SVG but by ODF Draw.



Comments (24)

  1. carlos says:

    why don’t you begin to reuse standards in

    your format ( OOXML ), throwing the VML deprecated beast and replacing Drawing ML with SVG, insted of criticize other formats that do their best to reuse standards?

    please, grow up


  2. Ian Easson says:


    – SVG’s vector graphics are a lot inferior in terms of capabilities to DrawingML’s.  That of course is why Microsoft did not use SVG.

    – Read the comments above, which showed that ODF did not "do their best to reuse standards".  Instead, they used an ad-hoc partially adopt / partially reject SVG!  In fact, they rejected the core of SVG (its vector graphics), and created something new instead.  (Which is what Microsoft did too — see my first point.)

    – There is every indication in the air that when the ECMA’s proposals for OOXML are published, it will show a great re-use of existing standards.  Just be patient a few days or weeks.

  3. Cmdr Flibberty Jibbitz says:


    It is an important point for Brian to raise because people have been accusing OOXML of not using existing standards and pointing out that ODF is smaller because "it reuses existing standards" which as it turns out it does not.

    It is "inspired" by other standards.

    Which in the light of the ongoing attacks on OOXML , specially when compared to ODF have less weight.

  4. S says:

    "Which in the light of the ongoing attacks on OOXML , specially when compared to ODF have less weight."

    Such a travesty.

    Why is OOXML 6,000 pages long if it reuses standards?

    If OOXML reuses standards, it means the aggregated document is probably a lot bigger. How much is it? 10,000 pages? 100,000 pages? How come we can’t even agree on that if OOXML is "open".

    As for other complaints about OOXML, I think it has been clearly brought since day one that it’s not entirely documented, that OOXML as is is more an internal tech specs than something supposed to become an international standards.

    In particular, Microsoft does not disclose the migration mapping tables for OOXML, even though OOXML is a migration format. It makes no sense at all. Why does not Microsoft open up the source code of the compatibility pack for instance? Does not this component implement said migration scenarios.

    That would be a start.

    What’s also said is that OOXML is not better enough to justify going to ISO. SVG could have been extended to support what Microsoft needed. Microsoft went their way because that’s in their DNA : they feel that the only way to maximize the lock-in is to reinvent the wheel at every turn.

    I need not document Microsoft past behavior. It falls flat in the face of anyone pro-Microsoft.

    The debate though needs not be that much polarized. Remember, a company dropped a bomb shell onto international standards organization. Not the other way around.

  5. S says:

    For those curious about OOXML, just take a look at the archived discussions that occured in US INCITS V1 (the US national body for ISO), where OOXML was reviewed :

    April :

    May :

    June :

    July :

    August :

    September :

    October :

    [ Microsoft reluctently approved the public disclosure, and imposed a few restrictions (US- only comments, etc.) ]

    It was brought to attention by the reviewing group that the scope and goal of the proposal was at odds with the content of said specs, and the claims could not be verified. Most notably, the "purely syntactic document conformance" statement in the goal is at odds. The review was leading to a rejection vote. After a phone call by BillG to the US secretary in august last year, the final US INCITS V1 ballot almost unanimously voted in favour of OOXML, despite the obvious nonsense of the entire proposal.

    For those thinking that the psychopaths in the Office team who should not be allowed to touch a keyboard ever again are isolated, just take a look at the Internet Explorer team :

    That should ring a bell.

  6. hAl says:

    [quote]SVG could have been extended to support what Microsoft needed.[/quote]

    How amusing.

    You hold seperate requirements for Microsoft.

    Why are you not asking why OASIS did not try to ask W3C to extend SVG to accomodate their needs as they actually claim to want to reuse web standards. At least Microsoft did not create their own SVG implementations and extend them like OASIS has done.

    If you had stated

    "SVG could have been extended to support what OASIS and Microsoft needed."

    we might have taken your comment remotly serious.

    And even than I wonder if some would ever try to go to W3C and ask them to change a standard because they want to reuse it and need it extended for that purpose. That would make for some amusement.

    [quote]even though OOXML is a migration format[/quote]OOXML is not a migration format. It is a full office document format that has an added capability to support high fidelity conversions from the currently nearly exclusivly used binary ms office formats.

    With access to the specifications of both formats it would be possible to create the mapping yourself allthough it might be a lot of work. However supporting complex office formats is a lot of work anyways and requires huge investments in time and money.  

  7. Mitch 74 says:

    About SVG:

    – right now OOo is unable to open ‘proper’ SVG files. What they do is implement an SVG-like language. Work is underway to make use of libsvg in OOo – at which time OOo will match the ODF spec

    – the ODF spec makes use of SVG. OOo is an incomplete implementation of ODF 1.0/1.1.

    – As far as I know, KOffice supports SVG – as such there is an SVG-aware released implementation of ODF.

    If you want to send curve balls, take this:

    – OOXML calls for password-protected Excel documents to use a formula. This formula is documented in the spec.

    – All versions of Excel from ’97 to 2007 make use of a hash formula that doesn’t match the OOXML spec.

    As such, Office 2007 doesn’t produce OOXML files; OOo however stated implementing OOXML file support, first with the OOXML documented hash formula, then with the custom Office 2007 hash formula.

    To sum up: OOo developer versions support OOXML according to specs better than released and patched Office 2007 supports OOXML according to specs.


  8. S says:

    "OOXML is not a migration format. It is a full office document format that has an added capability to support high fidelity conversions from the currently nearly exclusivly used binary ms office formats."

    The expression "added capability" is a fabrication of yours. When you remove that, you get what’s said in the scope of ECMA 376, which defines a migration format.

    To say that it’s a migration format is a quick and concise way to say what Microsoft has been saying for as long as this thing exists. They said they could not go ODF because they had so much legacy to preserve. They even claim that ECMA 376 serves different needs than ODF.

    All of that was disputed in US INCITS V1, France, and elsewhere.

  9. says:

    Mitch 74,

    The ODF spec says that passwords should be hashed… but it doesn’t say what hash should be used.


  10. marc says:

    so brian, Microsoft ( and by extension ECMA TC45 ) philosophy is something like this:

    "make it quick and dirty, but *make it*, we need this ISO stamp": i.e.

    throw the +6000 pages to the NB, they won’t cope with it, they will be overwhelmed by all this tables and repetitive examples, so they won’t understand anything and will vote "yes".

    we need formulae? copy and paste excel online help on DIS 29500  ( this formulae are no cross-vendor aware? don’t care, just put them on DIS 29500 to shut-up the zealots )

    we need password hash documentation? copy and paste some code in DIS 29500, no matter platform architecture dependence and interoperablity … NB are too fool to care about this

    we need VML and compatibility-settings for not changing code of Office 2007? put them on DIS 29500, 600 pages of VML on ISO throat, yeah!  

    and keep bitmasks in DIS 29500, we don’t care if XSLT books say "careful: don’t put bitmask on XML!": we drive de-facto standards! we make what we wan’t

    ( well, indeed, we had to add the word "linux", "firefox", "png" and "ogg" in some of the recent published ECMA BRM responses , but this open-source geeks will pay for that! )

    ODF interoperability? haha who cares? we *own* office market? why we need interoperability?

    they want pre-1900 dates? they will have it! add 2 more date systems to DIS 29500 and add ISO 8601 too… now DIS 29500 has five date systems ! don’t you like it ?  

    some "difficult" NB members don’t like some parts of DIS 29500 that we need to include because office 2007 code parses it? put them in deprecated annex, they will think that the parts have gone

    publish legacy binary format <-> OOXML  mappings to guarantee vendor-neutral backward compatibility and interoperability ?  good joke! just put another sourforge project as a PR proxy … NB officials will think that this is good ( they never try to download any project of sourceforge, is to geek for them, but they will think that we provided the mapping ! )

    some NB proposed that we split 29500 and re-submit the parts as  separated standards ? hahaha … we don’t have time for this: just re-arrange the parts in DIS 29500 and add some conformance text to give the impression of "separated" standard.. this is enough

    if all else fails, we have several national bodies that will put a "unconditional yes" sign just because we are Microsoft and have power and money, this NB ( with  JTC blessing ) have upgraded to p-member status ( they never cared about XML formats, they don’t have any expertise on the matter? who cares? the can vote at ISO, this is what matters! ):









    go on with the standards party ! you are enjoying it , ah?

    someday you can try some simple ( and effective ) way to develop (true) standards ( like C++, PDF , electrical or avionic standards ):



  11. says:


    You’re rambling is getting really old man. You are enjoying it, ah?

    A key to engineering is building something people can actually use. It makes the design much more difficult as you have to factor in all the conditions, and it’s not always pretty, but in the end it’s the only way to move people forward.

    You can continue your rants if you want, but look around. There are more implementations of Open XML than of ODF. The implementations of Open XML are also of higher quality. So you can claim that there are flaws in Open XML, but the marketplace says something else. I wish you would try putting the same focus on the ODF spec (or any standard for that matter), and see that there will always be designs you disagree with. The key is that the standard is interoperable, and anyone can use it if they want to.


  12. S says:

    Jones said "The implementations of Open XML are also of higher quality."

    There goes another ludicrous comment.

    Jones said "I wish you would try putting the same focus on the ODF spec"

    At the risk of surprising you, it’s you and your shills that keep coming up with ODF whenever you are out of argument. This blog is about OOXML, it’s pretty clear. There is no need to disparage ODF just to cover OOXML flaws.

    And yes, this is the worst spec ever.

  13. says:


    Could you provide a little information about yourself? What’s your name? What do you do for a living? Do you build software?

  14. Anonymous Coward says:

    S. is a troll. An illiterate version of marc. This is really all we need to know about him.

  15. Francis says:


    I would be hesitate to praise the C++ or PDF standards. It took about 25 years for C++ to become a standard *and* for interoperability its implementations to appear. See:

    PDF is likewise a can of worms. Granted, parts of the original OOXML proposal were taken straight from the Microsoft parts bin (e.g., formula documentation.) But PDF is no better! It’s simply a subset of PostScript–a proprietary, legacy programming language originating in 1970s laser printers. As such, it’s a highly complex standard. The official reference weighs in at 1310 pages.* No wonder nobody aside from Abode supports it in its entirety!

    (*This isn’t that much briefer than OOXML, when you consider the latter’s relaxed spacing and the fact that it is actually three standards in one–word processing, spreadsheet, and presentation.)

  16. Doug Mahugh says:

    Reading Reed. my colleague Reed Shaffner has started blogging. This should be fun. Reed is the driving

  17. Reading Reed. my colleague Reed Shaffner has started blogging. This should be fun. Reed is the driving

  18. S says:

    @Brian Jones

    Sure I write software, that’s why I only post a couple of times a day. What difference does it make to you? If I didn’t, would you point me to one of those XML for dummies tutorials that you guys write? Come on, I can’t think you would sink that low.

    Let me say it differently. I can sympathize with writing software that is used by a number of million individuals out there, and this is probably why something in you does it (I am talking about the part in you that is not completely rotten yet). But the more responsible it needs to be. When you write software that impacts so many people, you don’t rush software out the door (Office 2007) and you don’t rush and fast-track bogus specs whose content does not even match the goal and scope.

    Go back to the drawing board with it, make it something worthy. Perhaps then you’ll be taken seriously.

  19. marc says:

    >But PDF is no better!

    are you really saying that this

    has the same level of quality of this


    by the way… i read PDFs with 100% fidelity in more than four different open source programs in more than 4 different Linux distributions ( now writing this in Linux Mint, while i skim a 2000 page PDF document with "evince" a PDF viewer  ). This is what you get, when you design a format thinking in implementability

    ( Adobe publish detailed PDF specification since 2000 ,

    and when i say "publish" i’m not talking about complicated authentication processes with quid-pro-quo mailing , questions, fax sending, etc like Microsoft binary formats documentation supposed "availability" ).

    I will say it again: Microsoft, welcome to the open world. It will be difficult for you at the beginning ( it is an unknown territory for you ) ,but keep trying.

  20. Christian says:

    >Adobe publish detailed PDF specification since 2000

    >Microsoft, welcome to the open world. It will be difficult for you at the beginning

    Yeah, it really was difficult for Microsoft in the beginning: Like if they just implement PDF and Adobe forces them to remove that from Office!

    What an open format…

    And BTW: To DISPLAY PDF with 100% fidelity (Do you also mean 100% fidelity for 3D-cad modells, forms and javascript???) one just has to draw what’s in the document. Not that hard.

    But to RENDER Word-documents needs a complete layout engine! So it is unfair to ask for any open office standard to give one a direct route to reimplement the office appliacation!

    I think it is enough that MS documents the format, they don’t have to add 20000 pages with algorithms how to layout documents and how to draw them…

  21. Francis says:

    marc, Christian hits the nail on the head.

    Displaying PDF is one thing, but the PDF specification goes far beyond simple layout. For advanced PDF functionality, only Adobe’s own products work. None of the competing freeware or commercial implementations correctly handle the 3D, forms, and JavaScript Christian mentions 100% of the time. In fact, many of them lack even rudimentary support for these features.

    Their support for PDF is akin to those applications and filters that claim to support PSD (Photoshop) documents but only end up inserting a flattened bitmap.

  22. Dave S. says:


    Check, which offers the SDK, the docs, et al for working with PDFs.

    If implementations are not correctly handling the PDFs, it is more likely due to insufficient desire from their creators (time, money, ability) than poor support or documentation.


    "TO DISPLAY PDF … one just has to draw what’s in the document. Not that hard."

    A "layout engine" just displays the text where it is supposed to be in the document. If it was hard, then the software of the 70s running in <64k of memory would not have been able to do so.

    Algorithms have to be documented where the format description is insufficient to deduce what the result should be. Were it otherwise the MSO-XML spec could have one entry – Format_like_Office_2007.

    People complained when MS Office Windows opened MS Office Mac OS spreadsheets and all the schedule dates moved because similarly named applications from a single vendor used two different date origins. This because a serial number substitute for dates was interpreted using two different algorithms.

    I’ll go with Yes, algorithms that change the outcome need to be documented. They don’t need to be coded, but well enough described to be able to write software to execute them.

  23. marc says:

    "Do you also mean 100% fidelity for 3D-cad modells, forms and javascript???"

    "Displaying PDF is one thing, but the PDF specification goes far beyond simple layout."

    do you want javascript PDF documentation? look here:

    ( 680 pages of *useful* information, i mean you won’t find there 200 pages of repeated tables defining on/off attributes, like OOXML "documentation" )

    3d documentation? look here”>  ( "Multimedia" section )

    PDF forms and javascript implementation? do you know Scribus?


Skip to main content