Numbering formats in ODF

I was wondering if someone more familiar with the ODF spec could help me out. I had made the following reply yesterday to Alex's assertion that ODF was as feature rich as Open XML and I want to make sure that I'm not misstating things:

I think you might want to dig a bit deeper into the formats. ODF does build on existing industry standards, but at times they are partial implementations, and it still leaves out a lot. For instance, Open XML actually uses more of the dublin core metadata schema than ODF does.

Another easy example would be to look at the different types of numbering for a wordprocessing file. In Microsoft Office you can say that the numbered list should be "first", "second" and "third" instead of  "1.", "2." and "3.".  ODF doesn't support that.

That's just the beginning though. If you are from another country like Japan or China, there is absolutely *zero* mention for how your numbering types are defined. The spec only specifies:

  - Numeric: 1, 2, 3, ...  
  - Alphabetic: a, b, c, ... or A, B, C, ...  
  - Roman: i, ii, iii, iv, ... or I, II, III, IV,...

No mention at all about what you do for any other language. If you use OpenOffice, they actually do support other languages, and they even save out those other numbering formats into the ODF  style:num-format attribute. The problem though is that behavior isn't defined in the spec, so how does anyone else that wants to read that document figure out what OpenOffice's extension means? Maybe I'm just missing something, as the ODF spec is really vague in a lot of areas, but I looked around for awhile and couldn't find anything.

Even if you don't pay attention to the things that are just flat-out missing from the format, the documentation for the things it does support is pretty minimal. In the latest Ecma draft, we have about 200 pages discussing the syntax of formulas for spreadsheets, ODF has a few lines. That gives me the impression that no one that does accounting or works on Wall Street was involved in the standard because I can't really imagine them allowing it to go through without specifying how formulas should be represented. It's no wonder the few applications referenced as being "full implementations" of ODF aren't even capable of full interoperability (link).

Alex then replied with the following:

OpenDocument is well known to support  variety of languages, and the Japanese ISO member pointed out a couple of problems with the spec. (mostly to do with international URIs). I think they would have noticed if numbering was a problem. The guys in the middle-east were looking at it too.

You're absolutely right about formulas; OpenDocument does not specify a syntax, and that is something the TC is working on. There is a wider problem here, though: formula syntax is something users know directly. Should OpenDocument do something new, or just what Lotus 1-2-3/Excel did/do? OXML has the luxury of only caring about compatibility with Office file formats; OpenDocument is designed to be widely compatible with all.

I may have jumped the gun when I stated that there was *zero* documentation, but I'm curious to know where in the ODF spec these things are specified. When I looked at the numbering section (4.3 , 12.2.2, 14.10.2) it was pretty light, and only called out those three styles I mentioned above. In section 12.2.2 there is reference to the approach used in XSLT for the format attribute, but it just says the attribute is done in the same way, not the same actual formats. The spec then states though that it only supports a specific set, and that it does not support all the different types the XSLT approach uses. The spec says that the number styles supported are ("1", "a", "A", "I", and "I"). Let's assume though that the spec was just worded improperly and it does in fact use the XSLT format approach to the full extent. Then why does OpenOffice output Japanese numbering format like this:

The XSLT spec says that you only put the first character of the list in the format attribute (or at least that's how I interpret it). I didn't see any mention of the approach of putting the first three characters followed by an ellipses.

That was using Kanji numbering. The XSLT spec actually does call out directly how to do Katakana numbering, and OpenOffice actually doesn't do that properly either (the XSLT spec says it should format="ア" ). Instead, OpenOffice does this:

Now, for those familiar with Japanese numbers (and actually a whole host of other number styles) you know that it isn't always possible to represent a numbering style with just a single character . There are a couple different Kanji numbering styles that start with the same character (the difference is what you do once you get to 10). I assume that's why OpenOffice is going the route that it is.

Where is this approach documented though? Maybe I'm just misreading things here, and there is another portion of the ODF spec or the XSLT spec that allows for that approach? Or does this mean that if you are writing a Japanese document and use numbers with OpenOffice you aren't creating a valid ODF file? This newsgroup post implies that OpenOffice isn't yet fully supporting ODF so maybe that's the case? I suppose the response could just be that the format is extensible and you can place anything you want in that attribute, but how does that lead to interoperability? There's nothing to tell other applications how they should interpret that from as far as I can tell (again, I could be missing something obvious).

Almost every site I visit to find more information focuses almost completely on the marketing or political side of ODF. There are discussions around conformance, logo compliance, getting governments to support it, etc. etc. etc. I'm having a really hard time finding any good blogs or sites that discuss how to actually use it. I actually came across the oasis public mailing list archives that had some useful content, but I wasn't able to find anything about this issue.

-Brian

Comments

• Anonymous
  May 26, 2006
  You can always ask the OASIS Office committee, who are actually designing the spec. Microsoft are still members of OASIS, aren't they?
  
  But anyway, when I said OpenDocument was as feature rich, that doesn't mean I'm asserting that OpenDocument has every single feature that OXML necessarily does - it would need someone to go through each specification and find out what each one supported that the other didn't. We can list things either format doesn't support; but I don't think OXML is measurably "richer" than OpenDocument.
  
  OpenDocument is still undergoing revision, and there is going to be a 1.1 version in the not too distant future. I think Microsoft would be doing good for everyone by participating in those discussions: eventually, maybe we can even reconcile the formats?

• Anonymous
  May 26, 2006
  I've changed my mind.  Instead of bringing our office monopoly to play in pushing our own standard for fear of losing control of a standard and allowing interoperability, we are now going to do the "right thing" .  I decree that we dump open XML and work to add what we think is missing from ODF into it and adopt it.  We can compete on features.

• Anonymous
  May 26, 2006
  Alex,
  
  It seems to me you are attempting to suggest that you look forward with eagerness to a day in which the competition works together to service the greater interest/good of the public?
  
  Is this true, or am I reading too much into your comments?
  
  If yes, what would you define the greater good/interest of the public to be?  Is this even possible?  In a perfect world, where everybody found joy and happiness doing exactly the same thing as everyone else, and no one ever worried much about individualism, you might very well find a way to convince the competition that working together is the right, neighborly thing to do.  
  
  Maybe it is.
  
  But where's the encouragement to build better, more reliable products?  Wheres the motivation?
  
  What I have a hard time understanding is that I often hear people suggest that because Microsoft is a monopoly share holder of the desktop, it has caused them to become less innovative, less feature focused, and instead attempting to lull the users into accepting mediocrity with a smile.
  
  What's odd is that it seems to be the same folks who make statements such as this also believe that working together to create one document format is the right thing to do.
  
  So on one hand, the lack of competition due to the monopoly is a bad thing because it allows Microsoft the "luxury" of being less innovative, because there's nothing pushing them to do more.  On the other hand, there seems to be a belief that, in fact, lack of competition isn't a bad thing after all, and in fact a better world will result if we could all just focus on being less competitive in the office document space rather than more.
  
  Unless I'm missing a key element, then there seems to be a problem with the above paragraph.  The word double standard comes to mind, as do a few other things... but I dhould find out first whether or not any of the above is actually the case, or if theres something I seem to missing.
  
  Some fantastic commentary, by the way, comes from Rick Jelliffe yesterday on a post to his XML.com blog[http://www.oreillynet.com/xml/blog/2006/05/first_impressions_of_open_xml.html]:
  
  "I think there is substantial value in a standard XML format for MS Office documents even within organizations that will mandate ODF for interchange and archiving. The availability of the alternatives reduces the need for ODF or Open XML to be the one true interchange format."
  
  Rick is someone who has been through every phase of the standardization process at every level, and someone in whom very few people could match up against in regards to his overall experience in the document space, the stanardization space, and pretty much any other space he decides to put any of his time into.  One of the true Rare Gems of our industry.
  
  WIth this in mind, my own feelings are that I should pay attention to what he has to say on such matters.  In fact I do... You will even notice my follow-up comment at the bottom of the above linked post that brings this point out.  
  
  Experience counts.  Rick has that experience, that he then couples with his neutrality to either side to form opinions that I believe matter probably more than most anybody else that I personally have any sort of implied connection to (in regards to the fact that we're both XML professionals, writers, developers, and share a similar blogging space on XML.com/OReillyNet where we will communicate a bit back and forth.  I gues you could suggest we're colleagues in a sense, however given the fact that I learn more from Rick than I do most anyone else on this planet, its more of a student/teacher type connection in my eyes.
  
  He's a good teacher.  I would HIGHLY recommend reading his work, especially some of his latest posts.
  
  ---
  
  Hey Brian,
  
  Take a look @ http://www.tbray.org/ongoing/When/200x/2005/10/01/Open-Office-Conference#p-3
  
  "Bad Formula Trouble · I learned, to my dismay, that the ODF specification is silent on spreadsheet formulas, they’re just strings. This is obviously a problem; much discussion on what to do ensued. I lean to the idea, much bally-hooed by Novell, of simply figuring out what Excel does, writing that down, and building it into ODF v.Next. Mind you, anyone who’s really been to the mat with Excel, in terms of Math & Macros, knows that it isn’t a pretty picture, there are real coherency problems. But it’s good enough and the world has learned how to make it work."
  
  I believe you are spot on with your observations.  It seems Tim feels the same way.
  
  Enjoy your morning! :D ( and keep up the fantastic work! LOVE Office 2007, btw... THANKYOU!!!!!! )

• Anonymous
  May 26, 2006
  Alex,
  
  It seems to me you are attempting to suggest that you look forward with eagerness to a day in which the competition works together to service the greater interest/good of the public?
  
  Is this true, or am I reading too much into your comments?
  
  If yes, what would you define the greater good/interest of the public to be?  Is this even possible?  In a perfect world, where everybody found joy and happiness doing exactly the same thing as everyone else, and no one ever worried much about individualism, you might very well find a way to convince the competition that working together is the right, neighborly thing to do.  
  
  Maybe it is.
  
  But where's the encouragement to build better, more reliable products?  Wheres the motivation?
  
  What I have a hard time understanding is that I often hear people suggest that because Microsoft is a monopoly share holder of the desktop, it has caused them to become less innovative, less feature focused, and instead attempting to lull the users into accepting mediocrity with a smile.
  
  What's odd is that it seems to be the same folks who make statements such as this also believe that working together to create one document format is the right thing to do.
  
  So on one hand, the lack of competition due to the monopoly is a bad thing because it allows Microsoft the "luxury" of being less innovative, because there's nothing pushing them to do more.  On the other hand, there seems to be a belief that, in fact, lack of competition isn't a bad thing after all, and in fact a better world will result if we could all just focus on being less competitive in the office document space rather than more.
  
  Unless I'm missing a key element, then there seems to be a problem with the above paragraph.  The word double standard comes to mind, as do a few other things... but I dhould find out first whether or not any of the above is actually the case, or if theres something I seem to missing.
  
  Some fantastic commentary, by the way, comes from Rick Jelliffe yesterday on a post to his XML.com blog[http://www.oreillynet.com/xml/blog/2006/05/first_impressions_of_open_xml.html]:
  
  "I think there is substantial value in a standard XML format for MS Office documents even within organizations that will mandate ODF for interchange and archiving. The availability of the alternatives reduces the need for ODF or Open XML to be the one true interchange format."
  
  Rick is someone who has been through every phase of the standardization process at every level, and someone in whom very few people could match up against in regards to his overall experience in the document space, the stanardization space, and pretty much any other space he decides to put any of his time into.  One of the true Rare Gems of our industry.
  
  WIth this in mind, my own feelings are that I should pay attention to what he has to say on such matters.  In fact I do... You will even notice my follow-up comment at the bottom of the above linked post that brings this point out.  
  
  Experience counts.  Rick has that experience, that he then couples with his neutrality to either side to form opinions that I believe matter probably more than most anybody else that I personally have any sort of implied connection to (in regards to the fact that we're both XML professionals, writers, developers, and share a similar blogging space on XML.com/OReillyNet where we will communicate a bit back and forth.  I gues you could suggest we're colleagues in a sense, however given the fact that I learn more from Rick than I do most anyone else on this planet, its more of a student/teacher type connection in my eyes.
  
  He's a good teacher.  I would HIGHLY recommend reading his work, especially some of his latest posts.
  
  ---
  
  Hey Brian,
  
  Take a look @ http://www.tbray.org/ongoing/When/200x/2005/10/01/Open-Office-Conference#p-3
  
  "Bad Formula Trouble · I learned, to my dismay, that the ODF specification is silent on spreadsheet formulas, they’re just strings. This is obviously a problem; much discussion on what to do ensued. I lean to the idea, much bally-hooed by Novell, of simply figuring out what Excel does, writing that down, and building it into ODF v.Next. Mind you, anyone who’s really been to the mat with Excel, in terms of Math & Macros, knows that it isn’t a pretty picture, there are real coherency problems. But it’s good enough and the world has learned how to make it work."
  
  I believe you are spot on with your observations.  It seems Tim feels the same way.
  
  Enjoy your morning! :D ( and keep up the fantastic work! LOVE Office 2007, btw... THANKYOU!!!!!! )

• Anonymous
  May 26, 2006
  BillG, you should know that never works. You'll be accused of creating your own standard in a way that nobody can compete with you. It never worked. You couldn't influence OpenGL and now you play alone in the corner with Direct3D. The world ignored TruePage and went for PDF. They ignored VML and went for SVG. They ignored CSS behaviors and extended DOM with support for CSS selectors and event listeners
  
  Face it, Billy, the days in primary school when you were always picked last when choosing the volleyball practice teams will never be over

• Anonymous
  May 26, 2006
  Alex,
  this was just one example that a coworker of mine and I came across yesterday when we took a look at the ODF spec. It's not something I'm interested in drilling into specifically, my question is actually more general. I was curious to know where you are supposed to go for all the things that aren't covered in the spec.
  Based on the interoperability issues they are having, I'm sure there are other people wondering the same thing.
  
  It seems wierd to me that this spec would have been approved and finalized before it was even on par with the existing document base. I think I'm starting to understand though, as it's clear that the two formats just have two different goals. ODF was designed around simplicity and ease of use for developers. Open XML was designed to open the existing base of Microsoft Office binary documents. In doing so we focused on the developers, but we gave an even higher priority to the end users. We wanted to make sure there was no feature loss or significant performance hit. I don't see why it would be worthwhile to participate in the ODF work when we already have a format (Open XML) that meets our goals. And don't forget that we've been working on Open XML just as long as ODF has been in the works. We just had a more staged and spread out progression to get to the point we are today.
  
  Bill,
  glad to see you finally responded to all those e-mails and decided to check out my blog. I thought you were aware that we actually already have made the move to compete on features and not file formats. We created an XML file format that our end users will actually use. That means that we can move the existing base of binary documents forward into an XML format that has been fully documented and ownership has been passed on to an international standards organization.
  ODF isn't just missing functionality. It's fundamentally designed with different goals in mind. Looking at the spreadsheet format for instance, it's clear that basic things like performance have just been ignored.
  
  I'm not saying that the ODF guys messed up by not taking performance into account. I don't think it was one of their goals which is fine, you can't do everything. I think that they actually did a good job in achieving some of their other goals. I think they achieved their goal of creating a format that's simple for developers to work with.
  
  I don't think they've met their long term archivability goal yet, just because there is so much that's left out of the spec and viewed as an "implementation detail." How are we supposed to know what those numbering formats mean in 1,000 years if it's not in the spec?
  
  David, great points. There is obviously plenty of room for different formats. I can't understand why people would be so against the Open XML format when it's clear that the design goals were much different from ODF and that there are great reasons to have both. I can't tell if it's just an "anti-Microsoft" thing, or if they actually feel the same way about all the other document formats out there (like HTML, Docbook, etc.). Correct me if I'm wrong here David, but wasn't the "eXtensible" part of XML kind of significant... :-)
  
  Lastly, I love that someone named "KJK::Hyperion" is making fun of Bill for getting picked last in volleyball :-)
  
  -Brian

• Anonymous
  May 26, 2006
  Hey Brian,
  
  > Correct me if I'm wrong here David, but wasn't the "eXtensible" part of XML kind of significant... :-) <
  
  Hmmm...  You know, you might be right.
  
  I hadn't really thought about what the X in XML stood for, but I guess eXtensible is as good a guess as say, Xylophone?
  
  Although, to be fair, we should really give the Xylophone a fair shake at taking claim... I mean, how would you feel if you spent your whole life as the most well known lexical representative of a given character in the most wide spread language format, and then some poser comes along and say's "kick rocks, X! You've had your turn in the top spot long enough!  Its only fair that I should get a turn in the X position!"
  
  of which you would reply
  
  "but E, you don't get it, its hard being X, I mean there is this, and there't that, don't forget, and what about this over there, yes theres that!  But wait.." which of course you should not waste your breath, as E's spent his life  'tween loud D and loud F,
  
  The problem is this, no wait that, "What was that?"
  
  Oh, wait, now I get it.  Now I see, E is DEF.

• Anonymous
  May 26, 2006
  I think these kinds of details are key to the discussion.
  
  This is the first time I've seen an answer to "why isn't ODF good enough?" other than something broad and generic like "it doesn't meet the needs of our customers."
  
  I know that your goal is to focus on the OpenXML spec, and not specifically to bash the ODF, but I'd like to see more details of where ODF just isn't detailed or specific enough to work as a replacement of the binary Office format:
  
  * Does ODF even have a presentation-format?
  * If ODF leaves out a spec for spreadsheet formulas, does it say anything about graphs and charts?
  
  I'd also be interested in hearing about how the formats differ in how they've implemented certain portions of the spec--you've mentioned tag length (in the context of performance) and numbering, but these kinds of details can be very interesting.
  

• Anonymous
  May 26, 2006
  It's starting to look like ODF is the document format equivalent of POSIX. In other words, it's a standard which is supposed to make everything compatible with everything else. But it leaves so much behavior unspecified, implementation-dependent, or optional, that even a 100% POSIX-compliant system can be incompatible with major POSIX applications. Not to mention that most implementations also add new features and leave lesser-used ones out.
  
  Perhaps there will emerge some sort of autoconf for ODF, like an XSLT library to get KOffice documents to render properly in OOo and so forth.

• Anonymous
  May 26, 2006
  These gaps in spreadsheet formulas, numbering in languages, ... proves my key point: "lets use the same format and compete on features" is NOT possible.  Almost every feature needs a representation in the format and vice-versa.      

• Anonymous
  May 26, 2006
  Interesting that you picked numbering formats for comparison... I've asked several times on this blog about whether Word 2007 will fix autonumbering -- which for serious use has been broken since Word 97. Many technical writers have dropped Word and moved to FrameMaker (yes, or to OpenOffice) because of this one issue.
  
  All the wonderfully documented, feature-rich numbering specifications in the world don't mean a thing if the reference platform can't do the right thing with it.

• Anonymous
  May 26, 2006
  
  If X in XML stands for eXtensible, then L must stand for OLE.
  
  Indeed, if a document is password-protected, the new 100% XML Office will produce OLE documents instead of XML.
  
  (still waiting for an official answer on that one).
  
  

• Anonymous
  May 26, 2006
  Mike, if the file is password protected, then the password is used to encrypt the entire ZIP package, and the result of that encryption is just stored in an iStorage (which is a documented container format). If you have the password, then you can simply unencrypt it, and you're back to a ZIP package with XML again. If you don't have the password, than of course you can't unencrypt it. If you don't want to encrypt the XML, then don't password protect it. That's pretty straightforward.
  
  FARfetched, as you mention that isn't related to the formats themselves, but instead the application. We actually did improve the numbering behaviors within Word 2007 though, and you should check it out. Joe Friend is blogging about Word 2007, and he should be able to help you better understand what we've done around the automatic numbering behaviors: http://blogs.msdn.com/joe_friend/default.aspx
  
  -Brian

• Anonymous
  May 26, 2006
  All we need now is for someone to test Office 2007 Beta 2 performance with native format against OOo 2.0.2 native format. Then our dreams of starting a global nukular flamewar will finally come true! <g>

• Anonymous
  May 26, 2006
  I'd like to move up to Brian's general question.  
  
  I did a quick pass over the ODF specification last year and I identified two important characteristics.  First, ODF is underspecified in a number of respects.  Secondly, there is no solid conformance definition.  That is the same specification that was submitted to and recently accepted by ISO.  You can review my observations in the table entries at  http://nfocentrale.net/orcmid/writings/2005/06/w050601b.htm#3.5.1.7 and the subsequent rows.
  
  Another way to notice how products are dealing with the underspecification and extension of ODF is to examine the namespace definitions that are placed on the front of ODF package XML content.  I did a little spreadsheet experiment with OpenOffice Calc and noticed that there were three namespace declarations with URIs of the form "http://openoffice.org/2004/...".  The only one actually used was "ooc:" for introducing the formulas.
  
  My sense is that, thanks to XML, ODF users have a way of knowing where implementation decisions have been made, whether to compensate for an underspecification or to provide an extension.   I don't know how that will help provide assurance of acceptability in document interchange and the preservation of public documents.  I think that will have to be dealt with, and fairly soon.
  
  Two more observations.  First, I don't believe that ODF was seriously defined as a universal interchange format that could be used as a universal carrier.  I think some advocates believe that it is one.  I don't believe it about either ODF or OOX and I see no evidence of any effort to accomplish (as opposed to proclaim) such a thing: http://nfocentrale.net/orcmid/BlunderDome/clueless/2005/12/without-context-every-open-format.asp
  
  Secondly, with regard to formulas.  It is dangerous to make the syntax of formulas carried in spreadsheets be the format that the user edits.  For one thing, this creates problems with internationalization, including use of the local language for naming functions.  There is also an interchange (and language) problem if user-defined operators and extensions as well as product-defined extensions are to be available within the formulas of interchanged spreadsheets.   I have not looked to see how the OpenFormula team at OASIS and the ECMA TC45 team are handling these cases.  While I was on the OpenFormula project in its SourceForge beginnings, I know there was still confusion and misunderstanding on this subject.

• Anonymous
  May 26, 2006
  Goody, I was late: http://slashdot.org/article.pl?sid=06/05/26/1221220

• Anonymous
  May 26, 2006
  Dennis: interesting comment you make about formula syntax and i18n. When you start talking about the formula the users see be different to the one stored, I think that's a world of pain: translating expressions in such a manner that they are mathematically equivalent isn't necessarily easy. Formulas really are a special case here.
  
  One thing ODF does - and I don't know if OXML does or not - but it saves the value of expressions as well as the formulas themselves. So, if you read an ODF spreadsheet, you don't need to be able to calculate the result of a formula, you can get the pre-saved value (on the assumption it is correct; obviously if you changed anything, that wouldn't be true).
  
  Brad: ODF does have a presentation format, charts/graphs, etc. It relies a lot on SVG, which is a very well-defined graphics format.
  
  Brian: I think you're right about different goals; OXML is obviously designed to be an XML replacement for existing formats and ODF isn't. I don't think simplicity was necessarily a key goal for ODF: it's great that it is simple to implement, but I think that's a result of the design process.

• Anonymous
  May 27, 2006
  Alex, good points.  I also noticed that feature of ODF table cells and find it interesting and highly useful.  It is also apparently taking a while before implementations use that capability consistently.  (Booleans were one case that we stumbled on in comparing implementations in early days of the OpenFormula project.  I have not participated since shortly before they went under OASIS.)  In some sense, the ODF table cell might be bluring too much of presentation versus content coding.  It will be useful to see how it sorts out.  I still think its a clever idea and useful to try out.
  
  Concerning formula syntax, I don't think there is a semantics issue.  It is strictly about choice of syntactic elements and forms, punctuation ( [, ], ",", ".", ";", ":") and nomenclature.  (And of course, whether you go left-to-right or right-to-left in your language and in typing field entries.)  It doesn't seem like there is an issue about conformance of the definitions and arithmetic (or other) behavior, just the syntax and surface nomenclature.  You could come up with an equivalent reverse-Polish notation in the cells and never have anyone be the wiser (except to the degree that there are appearance features -- say use of white space or not -- that might get lost).
  
  This strikes me as a classic case for separation of presentation from state, you know?  I guess (I am being lazy here) that OOX and ODF need not deal with presentation and can deal with accurate communication in document interchange, including across locales and language choices.  There might be guidance on presentation, but I would hope focus is on the interchange and format level.  How this is expressed in the two specifications (OOX and ODF+OPenFormula) will be very interesting.

• Anonymous
  May 27, 2006
  Brian's question and what I recall about how ODF is underspecified led me to be nervous about something.  
  
  It is clear in ODF section 1.5 and in the way styles and formatting are handled, that a conforming ODF document can have some arbitrary attributes and elements in ODF metadata and ODF style properties.  (That a conforming application SHOULD preserve these under editing is an injunction that blows my mind and I will let that one go by.)
  
  It is also clear that the ODF-defined namespaces are not available for those additions.
  
  With regard to the popular case of border styles that has arisen lately, ODF apparently doesn't specify them at all.  The fo:border attribute is used and its value is simply a string.   It depends on what XSL says about these (although ODF uses a unique OASIS namespace to incorporate fo:border into ODF).  I'm not going any farther with that.
  
  With regard to numbering format in lists and headings and elsewhere, the ODF specification is very specific in defining  a style:num-format attribute whose only values are "1", "i", "I", "a", and "A".   There is another attribute, style:num-letter-sync that, when "true" modifies how "a" and "A" work.
  
  That's it for numbering format in headings and in lists.  It is perfectly legal to add a new attribute (with a distinct namespace) that expands this case.  Since there's a problem using it in place of style:num-format, it probably should be one that is used if understood and if not understood using the given style:num-format should be the graceful fallback.  
  
  But none of this is laid out.  I'm "being reasonable" with it.  Nevertheless, it seems very clear that adding values to the existing style:num-format is not in conformance with what section 1.5 says about how these arbitrary additions are to be introduced.  
  
  So, how do people agree on conforming use of some set of the additional styles and metadata?  I guess by publishing and stabilizing their namespaces and definitions and using each other's stuff (or using what some procurement body says must work).  Actually, I would add some of the many numbering styles from OOX, when it is published, in exactly that way, whether using an intermediary namespace (sort of one for the contracted use of agreed ones from OOX) or not, in just the way I described.
  
  We have a long way to go with all of this, and having these two momentous bodies of work (OOX and ODF) is going to teach us a great deal about specificity, rigor, and interchange agreements and profiles.  Having conformance suites for ODF is going to be important in the acceptance of ODF applications as fit for purpose.   OOX is a more-complex case and I'll stop my rambling with just that observation.

• Anonymous
  May 28, 2006
  > If X in XML stands for eXtensible, then L must stand for OLE. <
  
  Hmmm... well, since the play on letters was based on the notion that using X is technically innaccurate, yet using L for Language IS accurate, there's not a lot you can play around with to try and turn L onto OLE.
  
  Besides which, my attempt at humor was just that... an attempt at humor.  It wasn't intended to start a riot of any sort, so I am glad to see that it did not.  Either folks just smiled and moved on with their day or rolled their eyes to then move on with their day. something I have come to accept as fact that "many o' eyes will they roll" when I make yet another sad and unfortunate attempt at humor.
  
  Either way, I'm smiling, see > :D
  
  Anybody else have a smile on their face?
  
  I hope so... Life was meant to be lived with a smile. :)
  
  Enjoy your day :D
  
  
  
  Fortunately Brian already answered this

• Anonymous
  May 28, 2006
  Hmmm... Weird... not sure how the "Fortunately Brian already answered this" followed by
  
  However,
  
  > If X in XML stands for eXtensible, then L must stand for OLE. <
  
  ---
  
  Not sure how that got moved from the top to the bottom, and the "However," got cut off...  But I was using a VERY alpha/beta'ish browser when I made this comment, so to be honest... I'm not surprised.

• Anonymous
  May 28, 2006
  The comment has been removed

• Anonymous
  May 28, 2006
  Brian,
  
  I'm glad you chose to talk about lists. One of my obsessions.
  
  Your point about OpenDocument is a good one, and I expect that Open XML format to be more rigourous, but I'd like to point out some very serious, very long term problems with Word's list handling. While the file format is better designed that OpenDocument, Word's APIs and interface are really, really unspeakably awful.
  
  There is a way to create named list outlines, and a few new buttons in Word 2007 but there is no way to apply an named list through the GUI (not that I can find anyway).
  
  I have elaborated on this at my site: http://ptsefton.com/blog/2006/05/29/lists_in_office_2007._not_pretty.

• Anonymous
  May 30, 2006
  Brian-
  
  There is no comparison of Open XML to ODF. ODF is a universal file format made for many and all willing applications.
  

• Anonymous
  May 30, 2006
  Hi Sam,
  I agree that beyond being ZIP and XML, the formats are fairly different. The Open XML formats key design goal was to be compatible with the existing base of Microsoft Office documents. I'm not sure what the exact goals were for ODF, as it doesn't really appear to support many basic pieces of Office documents (formulas, international numbering, etc.)
  One could argue that the extensibility allows for such things, but that doesn't work for interoperability or long term archival. The few applications that do support ODF do so in different ways. In the example I used above, OpenOffice extends the num-format property in a way that doesn't even appear to conform with the specification.
  The two big arguments I've heard for mandating ODF is interoperability and long term archivability. Looking at pretty basic things (Japanese numbering) it appears to achieve neither.
  
  -Brian

• Anonymous
  June 01, 2006
  I've had a lot of folks ask me to provide more information on what features are missing from ODF and...

• Anonymous
  June 05, 2006
  As we move forward with the standardization of the Office Open XML formats, it's interesting to look...

• Anonymous
  July 05, 2006
  Today we are announcing the creation of the Open XML Translator project that will help translate between...

• Anonymous
  July 06, 2006
  Brian,
  
  I do not understand why do you make statements about OpenDocument such as "I'm not sure what the exact goals were for ODF, as it doesn't really appear to support many basic pieces of Office documents (formulas, international numbering, etc.)". The design goals are stated in OO website.    You just need to check them out.

• Anonymous
  July 06, 2006
  Oscar, the design goals seem to be far larger than what was accomplished with the first draft. Now it sounds like they still have a lot of work to do which makes me believe they didn't reach their original design goals and the current ISO spec should really be viewed as a partial spec and not complete.
  
  -Brian

• Anonymous
  July 07, 2006
  Whilst I can understand that ODF doesn't cover all possible features of an application, this shows to me two things:
  - as those features you mention already work in Openoffice they've preferred to  wait for an agreement in Oasis committe rather than use the existing implementation.
  - Xtensible Markup language: ODF compliant applications can implement their own version until agreement exists.
  
  I see ODF as a path rather than a finished state. Compliant applications still benefit as they can share all defined elements and still compete on implementation of additional features. After all, if Microsoft Office had all the possible features a user would need you wouldn't need to sell new versions?
  
  FYI one of the stated goals in the original Openoffice spec was: "The file format should be developed in such a way that it will be accepted by the community and can be placed under community control for future development and format evolution".
  
  It sounds to me more open than your open.

• Anonymous
  July 27, 2006
  The comment has been removed

• Anonymous
  January 23, 2007
  PingBack from http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=ac147359-114a-42d2-9ec4-64aa599dec58

• Anonymous
  July 26, 2007
  PingBack from http://www.25hoursaday.com/weblog/2007/01/23/WhatIsRobWeirAndIBMsAgendaWithTheOOXMLBashing.aspx

• Anonymous
  January 25, 2008
  A few interesting and entertaining links to end the week: IBM's Stance Against OpenXML Is Increasingly

• Anonymous
  January 25, 2008
  PingBack from http://msdnrss.thecoderblogs.com/2008/01/25/links-for-1-25-08/

• Anonymous
  January 26, 2008
  PingBack from http://softwareinformation.247blogging.info/brian-jones-open-xml-formats-numbering-formats-in-odf/

• Anonymous
  June 15, 2009
  PingBack from http://mydebtconsolidator.info/story.php?id=8408

• Anonymous
  June 15, 2009
  PingBack from http://debtsolutionsnow.info/story.php?id=6418

• Anonymous
  June 16, 2009
  PingBack from http://topalternativedating.info/story.php?id=3276

• Anonymous
  June 18, 2009
  PingBack from http://homelightingconcept.info/story.php?id=3727