Quick question for ODF experts

I must be reading this wrong, but in the ODF spec for tables it says the following:

"This chapter describes the table structure that is used for tables that are embedded within text documents and for spreadsheets."

Could it really be the case that ODF doesn't allow tables in presentations? I know that OpenOffice's presentation application "Impress" doesn't allow for native tables, but I had assumed the ODF format wouldn't have the same restrictions as OpenOffice.

Could someone more familiar with ODF help clear this up for me?

-Brian

Comments

• Anonymous
  July 20, 2006
  Native table support in presentations is slated for the 1.2 version of the spec. The recommendation until then is to use an embedded spreadsheet object.

• Anonymous
  July 20, 2006
  I believe it's slated for a future version. One reason should be apparent: presentation differences. It's fairly easy in a word-processing document to handle a table that's too long and/or too wide for the page, likewise a spreadsheet that's too large for the current window. Now, what do you do on a slide when it contains a table that's too wide and/or too long for a single screen? You can make an argument for scaling, but it becomes infeasible after about 2-3x. You can make an argument for scrolling, but you can make equally good arguments against it. Generating an error when you try to create it sounds good, but reasonable people might not agree with that. Truncation... is probably the only near-universally bad option. It obviously needs some more discussion to figure out how to accomodate everyone, and how to express that in the XML without being hard to work with, staying consistent and not breaking anything fatally when trying to do something else.
  
  But, as I said, we do know how to handle tables in word-processing documents and spreadsheets. It's hard to make the argument that well-understood and useful portions of the spec should be put on indefinite hold while more obscure portions are hammered out, so ODF isn't.

• Anonymous
  July 20, 2006
  An open standard is defined by an open process as well as an open specification fully implementable by all. You can openly read OASIS' mailing list and see for yourself: http://lists.oasis-open.org/archives/office/
  
  Of course you already do this in order to highlight every progress on the specification as a current shortcoming (Sic).
  
  ECMA TC45 on the other hand is a closed process. No open mailing lists just very brief summaries with no details on the actual work (if any) on the specfication like this: http://www.ecma-international.org/news/TC45_current_work/TC45-2006-50.htm
  
  Of course we - the independent developers - can read this blog and your point of view, and we do, but we can't judge the progress, the discussions, the points of views and the rationale behind the choices made. Is there any hope that you will actually listen to the questions raised on the newly published draft? E.g. http://www.robweir.com/blog/
  
  As I said an open standard is defined by an open process as well as an open specification fully implementable by all. Quick question: Could it be the case that ECMA TC45 is failing on both counts and thus OpenXML is not an open standard?

• Anonymous
  July 20, 2006
  Thanks for this kind question.
  Sure; OpenDocument allows tables in presentations.
  
  OpenDocument allows tables in presentations encoded in the following way:
  <draw:frame>
   <draw:object xlink:href="Link to OpenDocument spreadsheet table" />
  </draw:frame>
  For convenience the next version of OpenDocument will also allow tables in presentations to be encoded as follows:
  <draw:frame>
  <table:table>
  ....
  </table:table>
  </draw:frame>
  
  
  Talking about tables I have a kind question for the “ECMA Open XML” experts:
  
           Why do you need so many table models in your spec?
  
  I currently counted three different table models, but I’ve only quick scanned the 4000 pages spec. Would it not be better to use one table model, as done e.g. in OpenDocument?
  

• Anonymous
  July 21, 2006
  Probably for the same reason they have two, extremely similar, but slightly different ways of storing hyperlinks in Excel.  One in SpreadsheetML and one in DrawingsML.  The structures are almost exactly alike, but the target of the hyperlink is different enough to make it annoying to figure out if the link is to the current document or an external one.
  
  MS is not big on sharing code?  I've seen a several cases where they've reinvented the wheel.  Sometimes it makes one want to tell the developpers working on the different parts of the applications to, you know, talk to each other from time to time.
  
  On the other hand, I shouldn't really complain.  The new hyperlink structures are better than their old IHlink interface used in the binary.
  
  Also I can hazard a guess why there are at least two table models in the spec.  The concept of table in Excel is quite different from the concept of table in Word.  In Word you need to store all the heights, widths, cell merges, positioning, nesting, text, etc, etc that goes with the table.  In Excel, its mostly about formatting (borders, fills, fonts).  It doesn't control the size or position of cells in the grid, the cells (or really the rows and columns) themselves handle that.
  

• Anonymous
  July 21, 2006
  OK, this helps clear things up. Thanks.
  
  To quickly respond to the tables question, this really becomes clear as you have a better understanding of the different applications. Users of a wordprocessing document have different requirements for tables than users of a spreadsheet. The same is the case for presentations. Some of these differences are just properties on the structure, but other differences get down into the base structures of the tables. You need the seperate models so that you can efficiently respond to changes in the industry and customer demand. You don't want to hold off on improving the table model in presentations for example, just because it conflicts with what you are trying to do in a spreadsheet.
  Now, that said, we have focused on sharing as much of the underlying structures and design principles as possible, but at the end of the day, a table in a spreadsheet may contain 500,000 rows of data, and it doesn't really make sense for that structure to be identical to the structure of a table in a presentation which is primarily used for very small amounts of data.
  
  --- ODF folks ---
  
  Chris and Todd, thanks for replying so quickly with this. I had assumed if it wasn't already in the spec, it was something that would eventually get added. I understand that defining structures like tables in a presentation and formulas in a spreadsheet is hard and complex. Wouldn't it be more accurate though to say that the current form of the spec is more like a version 0.5? I know that OpenOffice doesn't support tables in presentations, but the more widely used presentation technologies like PowerPoint definitely do, and I can't imagine how a spec could be complete if it leaves out things like tables in a presentation and formulas in a spreadsheet.
  
  RequiredName, I could have looked through the mailing lists to find my answer, but I figured it would be quicker just to ask on my blog. I have a number of ODF experts who read this blog so I knew I'd get an anwer pretty fast.
  
  Florian, embedding a spreadsheet in a presentation is not nearly the same as having native table support.
  
  -Brian
  
  
  
  

• Anonymous
  July 21, 2006
  >Florian, embedding a spreadsheet in a presentation is not nearly the same as having native table support.
  
  That’s true Brian if you have three different table models. Since OpenDocument shares a common model the difference between the two options I outlined are just marginal. One is table declaration “by reference” and the other is a table declaration “in place”.
  
  Hope this helps clarification,
  
  ~Florian
  

• Anonymous
  July 21, 2006
  Florian, if you are linking to a spreadsheet object, how do you determine which application to load it with? Are you saying that a Presentation program should have the ability itself to load and render a spreadsheet object? Do they share the same style definitions and other resources?
  
  Does this mean that if I'm building a Presentation program, I have to support everything that is in a spreadsheet such as pivot tables and formulas?
  
  Don't you find that people creating presentations usually have different feature requests than people creating spreadsheets?

• Anonymous
  July 21, 2006
  I think, Brian, that one of the things the ODF people are trying to do is avoid having multiple table models. As noted, tables have slightly different requirements in different applications. It'd be nice, though, if they all used the same basic model with perhaps a few attributes specific to the usage in question. That simplifies any code that works with tables since large portions will in fact be common to all usages and only the parts that vary need to be coded to a specific variation. Note that one of the goals is something you noted: you don't want to hold up development of one thing just because of conflicts with another. MS choose to do that by using different models so one can be changed without affecting the others. ODF is choosing to use just one model, but to be careful about the base design and hamstringing so extensions can be done without breaking existing parts. This requires more up-front thought to avoid hamstringing, but once the first variation is done you end up with a large body of commonality that future extensions can take advantage of (eg. a word processor program can in fact read a presentation table natively and get it mostly right without having to understand presentation tables explicitly).
  
  I think a large part of your confusion is a radical difference in spec development methodologies. The waterfall model is to get the entire spec correct before releasing anything. The open-standards world (of which Unix and Open Source are subsets) takes the attitude of "Get the parts you understand well right and get them out there so you can get feedback, then move on to hashing out the parts you don't understand as well. Just make sure you think through the future parts enough to avoid making decisions now that'll hamstring you later.". Basically the word-processing portion of ODF is fully done, so it gets released as 1.0. Spreadsheet formulas may then be added and 1.1 released (which'll include all of 1.0 and be compatible with it). Native tables in presentations then get added in 1.2 (which'll include all of 1.1 and be compatible with it). People who don't care about spreadsheets or presentations, just word-processing documents, don't have to wait for parts of the spec that they, well, don't care about to be finished, and 1.1 and 1.2 can gain from any feedback about 1.0 that comes in before they're finished.

• Anonymous
  July 21, 2006
  Thanks Todd, I actually do understand that approach and I personally don't have any problems with it. I do think that this is the cause though of some of the problems people are seeing with ODF files. For instance, the spreadsheet format is super slow, and I think it's because they had to make it compatible with the text table model. The stuff that we do in SpreadsheetML around super efficient XML and string usage is something you'd only want to do if you knew that your application could have tables with thousands of rows (something you'd never get in a wordprocessing or presentation application). If you look at the open source application Gnumeric, it opens Open XML files much faster than it opens ODF files.
  
  All that said, I have no problems with the folks working on the OASIS spec. I know how much work it is and I respect it. The issue that I have a problem with is that there are organizations like the ODF Alliance who are pushing on governments to mandate ODF for document exchange. It would seem like this is putting the cart in front of the horse though since as you point out the spec really isn't done yet. Version 1.2 is slated for OASIS approval next fall (2007), and probably another 6 months to go through ISO. At that point it sounds like they will have some of the more glaring issues (like tables, formulas, etc.) covered. But to actually make policies around version 1.0 just doesn't sound like a good idea.
  
  -Brian

• Anonymous
  July 21, 2006
  Brian,
  
  thanks very much for your quick answers and the insights you gave into the ECMA work. I learned that you guys expecting heavy changes to the table models in “ECMA XML” in the future. This is why you want to keep the table models separate. That’s interesting to know!
  So you expecting “ECMA XML” to change in the future, right? Why then such comments about an “unfinished” OpenDocument specification?
  
  Regarding your initial question: “Yes of course; OpenDocument has support for tables in presentations and the encoding will even be improved --- following an open process”.
  
  ~Florian
  
  P.S. I'm really interested to hear what changes you expect for tables which makes you keep the models separate. Will they change dramatically? But I understand if you consider this to be a business secret and can't talk about it.
  Thank you so much for your sincere answers.
  

• Anonymous
  July 21, 2006
  Thanks for this kind question.
  Sure; OpenDocument allows tables in presentations.
  
  OpenDocument allows tables in presentations encoded in the following way:
  <draw:frame>
   <draw:object xlink:href="Link to OpenDocument spreadsheet table" />
  </draw:frame>
  For convenience the next version of OpenDocument will also allow tables in presentations to be encoded as follows:
  <draw:frame>
  <table:table>
  ....
  </table:table>
  </draw:frame>
  
  
  Talking about tables I have a kind question for the “ECMA Open XML” experts:
  
           Why do you need so many table models in your spec?
  
  I currently counted three different table models, but I’ve only quick scanned the 4000 pages spec. Would it not be better to use one table model, as done e.g. in OpenDocument?
  

• Anonymous
  July 21, 2006
  I think any slowness in spreadsheets isn't due to the ODF format, Brian. At least the OO.o spreadsheet program doesn't use the XML as an internal representation (as far as I know), so the XML syntax shouldn't affect anything beyond loading and saving (where speed isn't horribly critical since you're waiting on I/O a lot anyway). I suspect this seperation between external storage format and internal working representation isn't the way MSOffice applications work (Office's XML (old and new) both look to my eye to be a straightforward XML encoding of a COM object hierarchy).
  
  There's another rule that ODF is following: never optimize a general-purpose spec for a specific purpose. That kind of optimization leads to hamstringing: the optimizations tend to make it hard if not impossible to use for any other purpose, and you have to either suffer or create Yet Another Format for new purposes. The latter tends to be a headache down the road as more variations get introduced and formats for them multiply and other applications need to have more and more formats added to understand other applications.

• Anonymous
  July 21, 2006
  --- Florian,
  
  Did you mean to post that same comment twice?
  
  I understand that you can have a spreadsheet embedded in a presentation. That is actually far different than native table support in a presentation though.
  
  Of course the Ecma spec is going to evolve. I don't know how it will evolve, that's up to Ecma TC45. It's not like we're going to finish up version 1.0 and then just call it quits. As the different companies participating bring new ideas to the group we'll look at adding those into the spec. That's how you evolve software.
  
  The problem with ODF is that version 1.1 isn't adding new functionality that wasn't thought of at the point of version 1.0. Version 1.1 and version 1.2 of ODF are actually still adding functionality like tables in presentations and formulas in spreadsheet. Those types of technologies have existed for over a decade, and it's probably a bit dishonest to claim that a spec is complete and ready for everyone to use when it's missing such key pieces. Once we hit version 1.2 we'll have to revisit this.
  
  --- Todd,
  
  I'm sorry, but I'm going to have to disagree with you on a few of your points there. First off, the ODF spreadsheet format is extremely slow to load. There have been a number of articles discussing this (http://blogs.zdnet.com/Ou/?p=196).
  
  Second off, you should absolutely optimize your spec around specific purposes. Trying to design something completely generic doesn't do any good other than create a really simple lowest common denominator format that doesn't quite work in any specific situation. If you are building a format to represent spreadsheets, then you need to look at how spreadsheets are used. Go and tell the accountant or research analyst that the reason their spreadsheet file is so slow to open is that it was designed so that it could also be easily opened in a wordprocessing application and a presentation application. That's rediculous. It's fine as a low level interchange format, but not for a full fledged default file format. You need to look at how people use spreadsheets and design around that. The same is true for wordprocessors and for presentations.
  
  Now, if you look at the spec, there are a number of similar structures for tables between the three applications. This is especially the case between PresentationML and WordprocessingML because in those cases the user scenarios are often very similar.
  
  -Brian

• Anonymous
  July 21, 2006
  I had problems with the server. I got a "SERVER BUSY message" and then both comments appeared. Sorry. Using Mozilla; perhaps thats the problem ;-).
  Thanks for taking so much time laying out your opinion (flavored with some politics :-)). Really would have liked to work together with you guys in the OpenDocument TC.
  
  ~Florian

• Anonymous
  July 21, 2006
  Hey Florian, I actually get that same error every once and awhile too. So it's not just your browser. I've actually had times where I write up a big comment ane when I submit I get that message (I've actually usually lose the comments at that point though).
  
  Sorry about the politics, there's so much out there at this point it's hard to avoid completely. :-)
  
  -Brian

• Anonymous
  July 21, 2006
  Brian,
  
  I know you keep loving to state how "super-slow" ODF spreadsheets are. Do you have any numbers, other than George Ou's poor article?
  
  Comparing Excel loading files to OpenOffice.org is hardly a fair comparison of the basic speed of the format: I'm sure Excel loads files extremely quickly no matter what they are.
  
  It would be interesting if you actually had some numbers to back up your claims. Most XML parsers achieve a pretty decent speed, and parsing time is usually a really small proportion of the overall document load time.

• Anonymous
  July 21, 2006
  Hi Alex,  
  There are only a few things in this world that I love, and talking about spreadsheet performance definitely isn't one of them.
  
  I assume that your mention of parsing times is in reference to my post about smaller tag length. Remember that as I mentioned in my post, that was just one of the many things we did to improve the performance of SpreadsheetML. The shared string table and shared formulas have a much larger positive impact on the load times than the tag length.
  
  Now, I agree with you that comparing OpenOffice to Excel isn't really fair. The key is to find an application that supports both formats and compare them there.
  
  I tried that out with Gnumeric, using a smaller version of the file George Ou used, and Gnumeric opened Open XML files faster than ODF files. That's not the best example, because Gnumeric's support for Open XML is still in it's early phases (at least it was the last I checked), but it's still a pretty good initial measuring point.
  
  -Brian

• Anonymous
  July 21, 2006
  The comment has been removed

• Anonymous
  July 22, 2006
  
  Brian Jones said "The shared string table and shared formulas have a much larger positive impact on the load times than the tag length. "
  
  Gratuitous claim. Whether that's effective is directly related to the content. If you have no duplicate strings, or no strings by the way, then shared strings buy you nothing.
  
  Are we in 2006 Brian? How come Excel's new XML is just BIFF surrounded by angle brackets? How come developers will have to manipulate indexes (for instance to add a shared string) if XML is a first-class citizen? With a modern programming angle, shared strings don't exist because they are just an artefact of optimization. As long as it was buried inside BIFF and well taken care of by the Excel run-time, everything was fine. But now that this is getting exposed directly onto every developer's face, this becomes a hassle. While shared strings are optional, I don't understand why they exist in the first place in the new XML. May be you can give a clue or two?
  
  

• Anonymous
  July 22, 2006
  The comment has been removed

• Anonymous
  July 23, 2006
  The comment has been removed

• Anonymous
  July 24, 2006
  Come on Brian, must you always spin these details? Re: this in particular:
  
  "Wouldn't it be more accurate though to say that the current form of the spec is more like a version 0.5? "
  
  This is a ridicuously over-the-top comment. Sure tables in presentations ought to be there, and if MS had been involved with the TC, they would have been. You could have raised the issue, proposed a solution, and it woud have been there.
  
  AFAIK, apps like KOffice and OOo don't support this functionality in presentations, so it's not any huge surprise the developers didn't consider it a top priority. But the accessibility SC raised the issue, and it will be addressed shortly enough, along with formulas, and the metadata stuff I'm involved in.
  
  You can nitpick all you want, but we all know these are imperfect and evolving specs. For another view from the other side, read Rob Weir's blog.
  
  http://www.robweir.com/blog/
  
  He works for IBM and has a stake in all this too, but I think he has some good points and suggestions about OXML.

• Anonymous
  July 24, 2006
  "Wouldn't it be more accurate though to say that the current form of the spec is more like a version 0.5?"
  
  Brian, you are being too kind. Looks more like version 0.2 to me.
  
  No tables in presentations, no formulas in spreadsheets, no conformance criteria... Every day it seems that Sun and IBM are really trying to pull a fast one on several governments worldwide. Please keep it coming, someone need to expose this.

• Anonymous
  July 24, 2006
  It is spin indeed. MSXML has 4000 pages of documentation! Mostly documenting the way that MS Office does things. It seems a spec that no one is going to try and re implement in an office application -especially competing with MS Office-, and certainly not designed with simplicity or readability in mind. So many of the benefits of XML as an interchange document will not be achieved. Is a step in the right direction but as a customer I would be better served with a solid single Office XML format rather than re playing the format wars. It's just not in Microsoft (short term) interest to do that.
  
  

• Anonymous
  July 24, 2006
  The comment has been removed

• Anonymous
  July 25, 2006
  Oscar, yes the goal for a standard would be to allow free document exchange. Would you say that ODF as it is today satify this goal? Clearly not.
  
  <i>There should be a blog about statements from MS about competitors that are plain FUD or deliberately incorrect.</i>
  
  Are you suggesting that Microsoft should follow IBM's lead and create its own version of Groklaw?

• Anonymous
  July 25, 2006
  Oscar, your comment that Microsoft is "Mostly documenting the way that MS Office does things." has helped me clarify my understanding of the contentious issues about document format standards.
  
  To my mind, the ODF folks have not properly appreciated the significance of the fact that a document format needs to be judged, at least in part, in relation to the capabilities of the application that created it.  Once that is appreciated, it becomes possible to introduce two important concepts needed as part of the tools for judging a document standard: Completeness and Fidelity.
  
  Completeness means that the document format can represent all the different aspects of the document (structure, presentation).  For example, if a presentation application allows for tables in its presentations, then to be complete, the document format needs to be able to represent that there are tables in the presentation.  Fidelity goes further, and requires that the representation be 100% faithful to to original document's structure and presentation (as expressed in the application that originally created the document).
  
  The importance of completeness and fidelity is best understood by considering one important use of a document format: archiving.  An archived document needs to be able to be changed back at any time (though viewers or document translation software) into a 100% faithful representation of the original.
  
  To see why, consider the case of a government or company that wants to archive a legal document.  The meaning of that legal document can be affected by things you might consider unimportant for other documents, e.g., placement of commas or use of italics.  If the archived document is in a document format that is not faithful to the original application, then lawsuits might result because someone could claim they were damaged by the fact the the archived document did not accurately represent the intentions of the original document.
  
  Now it becomes understandable why Microsoft is "Mostly documenting the way that MS Office does things." They don't just want an open document format.  They also want completeness and fidelity with respect to documents produced in Microsoft Office applications.
  
  There is nothing wrong or sneaky about this attitude.  In fact, ODF supporters also want completeness and fidelity with respect to a small number of other office applications that they are associated with (not necessaily legally or organizationally, but emotionally and in terms of mindset).  Those office applications are clones of a small subset of Microsoft Office's capabilities -- the most commmonly used parts, of course.  Now, ODF by their own admission is probably a few years away from completeness or fidelity with respect to these particular applications.  But when they do achieve it, they will rightly be able to claim that the enhanced ODF provides a complete and faithful representation for documents produced by those specific office applications, and it is therefore safe to archive them in ODF format, or to interchange documents between these specific office applications.
  
  That does not mean that the future ODF will be able to completely and faithfully respresent documents produced in Microsoft Office applications. (The claim on their web site that they can do this is incorrect.)  The reason is practical: To be complete and faithful to Microsoft Office documents, the ODF folks would have to enhance ODF so much that it would be a virtual clone of OpenXML from Microsoft.
  
  Nowadays, the overwhelming majority of office documents produced today are created in Microsoft Office (except for PDF documents).  I hold the common view that this is not going to change in the forseeable future.  That means that in real life, ODF will never be able to properly represent anything other than a very small fraction of office documents.  That also means a fairly marginal future for ODF (in my opinion).

• Anonymous
  July 25, 2006
  Ian,
  
  First of all thanks for your comment.
  
  I don't consider myself part of the "ODF folks". I use and appreciate both MS Office and Open Office in Windows. Because I use both (some to a higher degree than others) I do not believe the statement that "the applications are clones of a small subset of MS Office capabilities". Both have advantages and disadvantages. Excel is clearly faster and more developed than Calc, but I actually use and prefer Writer as an application to MS Word.
  
  Going back to your comment, are you claiming that current versions of Word do provide a complete and faithful representation of Word documents created in previous versions of the application and/or in other platforms (eg. Apple)? This is not the case in my experience, and if you look around on the web there is plenty of similar experiences. On the other hand the current version of Excel has heavily and repeatedly corrupted critical spreadsheets on a crash that I only have been able to recover with Calc.
  
  In fact I doubt any program can claim complete and faithful representation of a document other than presentation-only formats like PDF (and possible the MS version of PDF) or a printout, unless you open them exactly on the same computer that produced them.
  
  What I want is to be in control of my data now and in the future, and being able to edit it with the program of my choice. I can take a JPEG picture with any digital camera and manipulate it with the software that better suits me. This is also the case for HTML but definitely not for MS Office documents.
  
  Your last paragraph is very telling of the conflict: "In real life ODF will never be able to represent anything other than a very small fraction of office documents", I take you mean MS Office documents. It seems to you the value is in the format itself, to me as a user is in what it does/doesn't enable me to do.
  
  Fernando: if by free document exchange you mean gratis yes, it enables me to share documents freely. (i.e. I think the standard version of Office for normal users is overpriced). If you mean the current version of ODF enables me to share documents I'd have to speak about specific implementations/programs, and who do I want to share documents with. I take your point that ODF is not complete  as a spec (i.e. formulas), but at the same time the new version of Office is not a market reality either and it won't be for a while in terms of amount of documents in that format.

• Anonymous
  July 25, 2006
  The comment has been removed

• Anonymous
  July 25, 2006
  In my post last week about the lack of table support in ODF, some folks were curious as to why the Ecma...

• Anonymous
  July 26, 2006
  The comment has been removed

• Anonymous
  July 26, 2006
  Ian - didn't mean to misinterpret.
  
  We have been working with WordML since it's inception in a commercial product.  I have also had a few conversations with Brian (and others) about Microsoft's direction with future Office XML.  I will admit to being one of those that want MS to succeed in making a very good XML-format.  I am less worried about it becoming an international standard, but I see how it will help.
  
  My gripe with MS has been in how it interprets WordML.  The example I can give you is a simple one, but still telling.  It is possible to state a size for a header or footer that is not big enough to hold the text and/or graphics placed in it.  Now, give this WordML to multiple viewers, including Word.  Some will show the header and correctly show that it is wrong.  Some will refuse to show the file at all, saying the header is broke.  Word will show the header as it should have been had it been done correctly.  Which was correct?
  
  With this next go, I would like something more rigid.  If it was the fault of WordML being too ambiguous, then I want the ambiguity removed.  If some form of XML tester existed, you could at least ask "Is this OK?", sort of like lint used to be for the C language.  There's no question that the XML schema will be complex enough to warrant one.
  

• Anonymous
  July 26, 2006
  I know nothing about the details you're talking about Rick (though I've had it confirmed to me by people who would know), but I wonder if any ambiguity in the schemas is more a limitation of XML Schema? There are a lot of practical, real world, constraints that simply can't be expressed with the language. For those cases, you either need to use Schematron alongside XML Schema, or use a better schema language, like RELAX NG.

• Anonymous
  July 27, 2006
  The comment has been removed

• Anonymous
  July 29, 2006
  Ian,
  
  I don't consider myself a "Microsoftphobe" just because I want a wide choice of software available. I probably would call myself "promiscuous". :-). Anyway, to your list I would add:
  d) Believe their data is their own and do not want to be restricted in the application they use to edit it.

• 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
  May 26, 2009
  PingBack from http://backyardshed.info/story.php?title=brian-jones-office-extensibility-quick-question-for-odf-experts

• Anonymous
  May 29, 2009
  PingBack from http://paidsurveyshub.info/story.php?title=brian-jones-office-extensibility-quick-question-for-odf-experts

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

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

• Anonymous
  June 17, 2009
  PingBack from http://patiosetsite.info/story.php?id=923

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