Over halfway there… including some positive changes to the Open XML standard

Article
12/11/2007

I had mentioned that the members of Ecma TC45 all met last week in Kyoto to continue working through the national body comments we received as a result of the ISO ballot for Open XML. We've been making a lot of progress over the phone the past couple months (we have 3 hour calls twice a week), but it's always productive to meet face to face and really get through some of the more difficult pieces.

Today Ecma has updated the proposed dispositions' portal for the comments that national bodies can go and reference. We're a little over 50% of the way through the 3500 comments received. If you read the status report released by TC45 you'll see that there have been some pretty significant changes proposed so far, and you'll see more are on the way. Here's a link to the TC45 report: https://www.ecma-international.org/news/TC45_current_work/New%20set%20of%20proposed%20dispositions%20posted.htm

Here's a list of some of the changes that were proposed in this batch:

1 Allowing for ISO-8601 Dates

ECMA-376, the original Open XML standard adopted by Ecma, assigned a unique numeric value to each date in a spreadsheet, in order to improve the speed of date calculations. Based on the comments received from some National Bodies on this issue, DIS 29500 will be updated to allow date values to be stored using the format defined by the ISO 8601 standard.

2 Internationalized handling of weekdays and weekends

ECMA-376 allowed for a week that begins on Sunday or Monday, but not a week that begins on any other day, such as Saturday. Ecma is proposing a comprehensive range of options for what is defined as the first day of the week, and what is defined as the weekend.

3 Language tags

ECMA-376 used a set of integer values to identify the language applied to regions of a document. Ecma is proposing that the language tags specified in the DIS should instead leverage an internationally recognized practice for representing languages, IETF BCP 47. IETF BCP 47 is a Best Current Practices document that incorporates use of the ISO 639 standard for languages, ISO 15924 for scripts, and ISO 3166 for regions. This proposal directly follows recommendations from National Bodies in several countries.

4 Page Borders

ECMA-376 included support for a variety of graphical elements that could be used as page borders. Several National Bodies noted that this closed list of graphical elements was not sufficiently diverse and global in its contents. Based on that feedback, Ecma is proposing to change the Open XML standard to allow for custom page borders. This will enable implementers to determine the best option for including borders relevant to their applications.

5 Usage of ISO standards for grammars

ECMA-376 used its own notation for defining the grammar for some of the more advanced functionality, such as spreadsheet formulas and word processing fields. Several National Bodies noted that the existing grammars in ECMA-376 are non-standard and were not fully described within the DIS. In response to this concern, Ecma proposes to revise the notation for spreadsheet formulas and fields to use an existing ISO standard. Formula notation will now use ISO/IEC 14977:1996 – Syntactic metalanguage – Extended BNF. This proposal improves the ability for implementers to test and validate conformance to the specification.

I was surprised to hear from a number of people that they were skeptical TC45 would accept any changes to Open XML. TC45 is excited to work closely with the national bodies and investigate what the best solution would be to these issues (including of course changing the specification). While its tough news in certain ways for me as an Office developer; it's great news for me as a TC45 member. We had made some design decisions within TC45 that many of the national bodies disagreed with, so we took that feedback into account and came up with proposals we think will address the national bodies concerns.

Jan van den Beld, former head of Ecma international, had a post this morning talking about his thoughts on the progress we've made so far: https://janvandenbeld.blogspot.com/2007/12/number-of-proposed-dispositions-for-nbs.html. Jan is impressed by the progress made, and also shares his thought on how many comments per page you would typically expect to get.

We still have a ways to go, and those of you following along know there are a number of other contentious issues we haven't finalized on yet (but we're getting very close). I'll provide more detailed explanations of many of the responses over the coming weeks, and I'm sure you guys will find those interesting.

-Brian

Comments

Anonymous
December 11, 2007
The comment has been removed
Anonymous
December 11, 2007
We're seperately working through the issues of date limits (ie what's the range of dates); as well as the leap year bug. I think we have good solutions for both of those as well within TC45, but we are still in dicussions on the final design. -Brian
Anonymous
December 11, 2007
What happened with the existing list of page borders. Did you scrap it from the spec, make it an annex or is these new custom borders a feature of extending on them ?
Anonymous
December 11, 2007
Does this mean all those OOXML documents I have made so far will be incompatible with the eventual ISO standard?
Anonymous
December 11, 2007
[quote]Does this mean all those OOXML documents I have made so far will be incompatible with the eventual ISO standard?[/quote] Office Open XML should supports versioning. So you are using Office Open XML 1.0. The currently being standardized version might lead to a Office Open XML 1.1 version Generally a new version is fully compatible and it should be easy to convert to the new version if you want. Even if some features are dropped they still could be supported by extension or embedding mechanism so your data would not be lost.
Anonymous
December 11, 2007
Keep up the good work. Clearly, this is a huge job, but it is encouraging to know you have handled so many comments. I'm looking forward to seeing the revisions that get hammered out if this makes it through the BRM. As you know, I am one who has had serious reservations about the spec, but this level of focus and effort is good to see.
Anonymous
December 11, 2007
How will Office be updated to support any changes in the file format, and what will happen with regards interoperability with old files and the compatibility packs for older Office?
Anonymous
December 11, 2007
The comment has been removed
Anonymous
December 11, 2007
Hi Brian, first of all congratulations on your progress. That's something I wanted to hear about for a long, long time and I'm glad that Microsoft and Ecma are finally starting to fix serious issues in the spec. Yes, sometimes it's painful, but that's part of the job. I do agree with omz that it's a bit sad that this is happening so late in the game, and as I've said before if OOXML had not been fast-tracked a lot of the current conflicts could have been avoided. Still, better late than never, right? Hope to read more from you soon, keep it up!
Anonymous
December 11, 2007
"DIS 29500 will be updated to allow date values to be stored using the format defined by the ISO 8601 standard." I take it from the language used that ISO 8601 dates are not required, and that the old integer format can still be used. Which means that all applications that implement OOXML still have to implement 20-year old bugs. This does not ease creating independent implementations in the slightest, and in fact complicates it now that there are two different ways to do the same thing, one of which is still broken in subtle and surprising ways. Do you guys miss the point on purpose, or are you really this stupid? What's that saying ... sufficiently advanced incompetence is indistinguishable from malice. Fail.
Anonymous
December 11, 2007
Karellen, may I congratulate you on the best corollary of a Clarkism (or any-ism) I've seen in quite some time. Malice indeed. Thanks for that. Dave P.S. Brian - it's "separately" not "seperately". Trap for young players. Just remember "a rat". Oh yes, it just occurred to me that perhaps your proprietary browser doesn't indicate spelling errors like my open source one does.
Anonymous
December 11, 2007
Of course we would wish now that ODF had the same kind of scrutiny. It might have explained what ODF means by a glyph or by an ideograph-alpha value because the specification seems to completely lack info on what those mean (making such items completly impossible to implement purely based on the ODF spec)
Anonymous
December 11, 2007
@karellen All current regular spreadsheet implementations already support decimal date values and have been doing so for more than twenty years. Supporting decimal values is much easier for spreadsheets than supporting ISO dates. It is actually the addition of ISO dates that might make more work for independant spreadsheet implementations support as not all of them already can handle the ISO format subset. (of course not a single spreadsheet implementation is able to handle the full ISO 8601 standard implementation because of it's complexity)
Anonymous
December 11, 2007
Some common sense on date formats, at last! Congratulations; you are now where you should have been a year ago (and that's being generous to you). These kind of changes are so not what ISO Fast Track is all about. This should have been sorted way before you ever got to Fast Track submission, not two months before the final BRM. But then, it doesn't sound like it's even sorted now, does it? We have some kind of agreement to implement some kind of ISO 8601 date compatibility, but the how is not yet specified. Will it be the default? Will it be a requirement, or as Karellan asks, will implementers still be free to use the old, buggy integer format? You really gonna have all this ready for February, with reference implementations to demonstrate? Methinks not. In truth, you're going to be asking the delegates to vote on a load of Microsoft promises, are you not? And we all know what they've been worth down the years. Cheers,

Mike "man of the people"!

Anonymous
December 11, 2007
Mike Brown, ODF 1.0 wasn't ready for prime time in the least, yet ISO rubberstamped it based on promises that it would improve in future versions. Promises that are still unfulfilled, btw (ODF 1.1 was finalized by OASIS almost a year ago, yet hasn't been submitted to ISO yet (i.e. ISO ODF is still utter trash)). But I didn't see you or your kind raising any issues regarding it. BTW, why do you anti-OOXML people even post here? You hate OOXML, we get it. Now leave.
Anonymous
December 11, 2007
The comment has been removed
Anonymous
December 11, 2007
The comment has been removed
Anonymous
December 11, 2007
@Reggie, >> ODF 1.0 wasn't ready for prime time in the least, yet ISO rubberstamped >> it based on promises that it would improve in future Says you. But that's by the by now, isn't it? ODF did pass ISO standardisation, and without its supporters having to pack the vote with their stooges either. The question now is whether OOXML should do the same. I don't believe that it should. >> Now leave. Not a chance, matey! Cheers,

Mike

Anonymous
December 11, 2007
As Ecma announced today, the project editor (Rex Jaeschke) now has proposed dispositions for over 50%
Anonymous
December 11, 2007
The comment has been removed
Anonymous
December 11, 2007
As Ecma announced today, the project editor (Rex Jaeschke) now has proposed dispositions for over 50
Anonymous
December 11, 2007
The comment has been removed
Anonymous
December 11, 2007
Mike, @Reggie, >>> ODF 1.0 wasn't ready for prime time in the least, yet ISO rubberstamped >>> it based on promises that it would improve in future > >Says you. Well, I do too. There are huge holes in the specification where the most prominent one is missing specification for spreadsheet formulas. Other examples could be mis-use of existing standards where it has been either extended, modified or delimited. How can you with any reason say that you have a format for spreadsheets - and then exclude specification for formulas? > But that's by the by now, isn't it? ODF did pass ISO standardisation Yes - but what I and others are simply politely asking is to have the same standards applied to approval of OOXML as was the case with ODF in a sense as "If it was ok with ODF, surely it must be ok for OOXML as well". Sadly, to me this doesn't seem to be the case. ODF flew through ISO because no-one cared about it except those supporting it. I attended the ISO/JTC1/SC34-meeting in Kyoto, and I was really surprised to see how easy it was to be able to put something through if noone cares. If only ODF had been through the same scrutiny as OOXML, maybe the list of 100 defects published by a single man Dr. MURATA Makoto (isn't he now convenor of SC34/WG1?) at http://www.jtc1sc34.org/repository/0942.htm would have been fixed before acceptance ... along with the comments from the final vote, which have all been ignored. Some of the defects are trivial and spelling errors, but some are actually quite serious since they allow interpretation of how to implement ODF and even induce errors. :o) /Jesper
Anonymous
December 11, 2007
@Jesper I think there's another possible interpretation of the increased scrutiny of OOXML in comparison to ODF. People voted Yes with comments for ODF, and then realised that this wasn't a strong enough option to get the comments addressed. They have learned their lesson, and now choose to vote No with comments, in the hope that this ensures OOXML gets fixed before approval as a standard. The "people" I refer to here are neither ODF nor OOXML supporters/opposers, they're just professionals who want to see standards that are fit for purpose. You are right that ODF 1.0 has flaws. ODF 1.1 fixes lots of them, and ODF 1.2 fixes even more. OASIS need to submit back to ISO of course, as these versions are not ISO approved. This is not a broken process though, it's working. ODF 1.1 was implemented into OpenOffice over time, and I have every reason to think that 1.2 will be as well. The comments you reference were posted this December - there's no reason to think they won't be addressed is there? Anyway, my key point is that your reasoning is "if it was ok with ODF, surely it must be ok for OOXML..." but that another reasonable point of view is that it wasn't right for ODF, and it isn't right for OOXML. We can see that ODF is being improved appropriately, so that mitigates the "mistake" but doesn't make it a good idea to repeat it. BTW, I'm a customer, not a developer or a vendor, although I can appreciate those points of view. When I speak of these things, it's with the point of view of someone who is trying to actively manage their suppliers to deliver what my organisation needs. I give Sun, IBM, MS, Oracle, Novell, whoever, a hard time when necessary, and thank them when appropriate too. We work in a mult-vendor environment, so interoperable standards are hugely important.
Anonymous
December 11, 2007
The comment has been removed
Anonymous
December 11, 2007
Mike, Another thing: You say: "But that's by the by now, isn't it? ODF did pass ISO standardisation" Ok - let's make a deal, then. We all accept the state of the world we live in, and I'll stop talking about how ODF was rushed through ISO, how vendor-controlled it is by Sun and IBM and how flawed it was at the time of submission. I will then expect you (and others) to stop whining about why Microsoft didn't use ODF and why Microsoft chose to submit OOXML to ISO. We are where we are - and by leaving these things out of the discussion, we could possibly spend our time discussing things that matter ... like technical merit of the disposition of comments. Deal?
Anonymous
December 11, 2007
Wow--what great news. I am really impressed the sample changes above. They go to show that ECMA and its partners genuinely do care about the process and the standard that emerges. Incidentally, please make sure that when you allow for ISO dates, that traditional-style dates are extended backwards to include pre-1900 dates. This would simplify historical research and reconstruction (e.g., with old stock market values, geological records, etc.) It's also highly gratifying to see formulas and fields move to a standard notation. I hope part of this change will also be a provision for the use of portable and relative URIs (instead of absolute MS-DOS paths) in Word fields. Keep up the good work!
Anonymous
December 11, 2007
The comment has been removed
Anonymous
December 11, 2007
The comment has been removed
Anonymous
December 11, 2007
The comment has been removed
Anonymous
December 12, 2007
The comment has been removed
Anonymous
December 12, 2007
@Jesper You said is best and clarified Microsoft position: "but the OOXML vs. ODF battle is not about the formats; it's about market control." The transition from Microsoft's defacto .doc format to a Microsoft defacto XML .docx format is just about that, nothing more and nothing less. It is only about lock-in and force up-grades for the self-proclaimed Overlord of office documents. Statements on why OOXML is an "Open Standard" continue to be preposterous. It simply is not on every level. Please refer to David Lane comments as the only reasonable way for Microsoft to be welcomed into the world of "open standards". Meaning open to all and welcomed by all.
Anonymous
December 12, 2007
Suite aux réunions qui se sont déroulées la semaine dernière , l'ECMA a annoncé quelques modifications
Anonymous
December 12, 2007
Dear Brian, Do you think ECMA can publish a working draft. I know about the problem with NBs comments should be kept confidential and it is not ECMA's right to unilaterally waive this confidentiality clause. However, there are several ways around it. The low tech way will be to "black out" the confidential part. Another will be to publish only the proposed changes to the already public OOXML proposal. Things like using ISO dates alongside integer values raise anxiety level. On one hand, it is great that we can use ISO dates. On another, does it means conforming implementation must implement both integer and dates? There are other questions that needs answering as well, such as is the ISO dates restricted to the same range as the integer dates format etc. The sooner we can discuss these issues the faster we can work out issues like this and this can only be to the benefit of OOXML ISO process.
Anonymous
December 12, 2007
The comment has been removed
Anonymous
December 12, 2007
Jesper, you are incorrect in saying that SC34 voted to accept OOXML as a fast track submission. I'd be interested in hearing where you got this false impression from. First, SC34 does not vote anything on Fast Track submissions. JTC1, the parent committee, does that. Second, even JTC1 has no input on whether a Fast track is accepted or not. The JTC1 Directives 13.1 clearly say that "The criteria for proposing an existing standard for the fast-track procedure is a matter for each proposer to decide." There is nothing in the process where JTC1 or SC34 NB's are asked whether they accept the submission. The only opportunity they have is to vote 'No' after the 5 month ballot. This lack of a "gag reflex" in JTC1 procedures is a defect in the system, IMHO. I think it would have been better for everyone if OOXML had been quickly examined by experts back in 2006, the presence of serious flaws noted, and the submission immediately rejected at that point. Ecma could have then used all of 2007 to make fixes, rather than trying to do it all in a few short months. In any system, human or computer, the ability to have a fast failure mode is essential. If it is impossible to fail any Fast Track in JTC1 until the proposal has been in the process for 15 months, then the system has a serious problem.
Anonymous
December 12, 2007
The comment has been removed
Anonymous
December 12, 2007
@Rob: I think it would have been better for everyone if ODF had been examined by experts, (even a 100th of the number involved in reviewing OOXML) the presence of serious flaws noted, and the submission immediately rejected at that point. OASIS could then have made fixes, rather than trying to do it all in a few short months.
Anonymous
December 12, 2007
The comment has been removed
Anonymous
December 12, 2007
@Reggie, Microsoft seems to whine alot whenever they have competition. Is this for lack of practice? Rather than changing the subject, in the "hit and run" style of the numerous Microsoft fanboys here, why don't you address the question of the quality of OOXML as it was submitted to JTC1. Do you believe it was a prudent thing for the proposal to be made in this condition? Was it respectful of the time and resources of JTC1 and JTC1 NB's who had to review this seriously flawed 6,000 page specification? You imply that you were not pleased with the quality of ODF. Do you believe that this excuses or justifies the submission of OOXML? Should the submission of OOXML then justify or excuse the submission of further standards by Microsoft or others of over lower quality? Where does this logic take you in the end? Is the goal to be the lowest quality standard ever? Is that your aspiration? Is that the best you can come up with? Is that your argument for ISO approval?
Anonymous
December 12, 2007
Rob, I appologize for not being clear (or actually wrong about this), because as you said SC34 did not vote for allowing OOXML access to Fast-Track - the JTC1 secretariat did. I am sure you already knows it by heart, but otherwise look at section 13.3 and 13.4 in JTC1 Directives ( http://www.jtc1sc34.org/repository/0856rev.pdf ). So you are correct - SC34 did not vote on accepting OOXML on fast-track, but the fast-track DIS procedure consists of a initial 30-day review period where objections from NBs could - and was - submitted. JTC1 then decided based in these that OOXML could actually continue with the 5-moonth review. You conviniently left this part out. But, you know, this actually clearly hightlights the problem with what you are saying. It is not as much /what/ you say - it's what you do /not/ say. An example of this was you using the contact list of SC34 as basis of your argument, that very few NBs have asked for the password+username of the protected website. For anyone outside of the process they might look at the list and think: "Gee, that's a short list" ... but the list has nothing to do with what you are saying. Based on the list, Denmark should not have asked for access - but we have. :o) /Jesper
Anonymous
December 12, 2007
Rob, sounds to me like you want the world to hold OOXML to a higher standard than they did with ODF. Thats oddly both noble and sinister.
Anonymous
December 12, 2007
The comment has been removed
Anonymous
December 13, 2007
@Jesper, The 30 day period was purely for raising the issue of contradictions with existing ISO or IEC standards. That was the only topic that could be discussed. That was not a period where objections could be considered that the standard was too large or inappropriate for Fast Track processing, or that the quality was too low. The Directives have no "quick failure mode" for proposals that are clearly inappropriate. The JTC1 Secretariat merely decided that the numerous allegations of contradictions could not be resolved, and that the process should proceed to the 5 month ballot. this is allowed by the Directives. You earlier said, "SC34 voted on allowing EOOXML as a fast tracked proposal". I think it is clear that this statement was not accurate, or even close.
Anonymous
December 13, 2007
Dear Rob, "You earlier said, "SC34 voted on allowing EOOXML as a fast tracked proposal". I think it is clear that this statement was not accurate, or even close." Yes ... and I said: "I appologize for not being clear (or actually wrong about this), because as you said SC34 did not vote for allowing OOXML access to Fast-Track - the JTC1 secretariat did." What part of this is not clear to you? :o) /Jesper
Anonymous
December 13, 2007
@Jesper, Just pointing out that your statement that the JTC1 Secretariat decided that OOXML was suitable for Fast Track processing was also inaccurate. No one other than Ecma has a say in whether a proposal is suitable for Fast Track processing. Note that this process has been far from clear or easy-to-understand. JTC1 Directives are poorly written, and parts of the process have been improvised. So I don't blame anyone for getting confused. Not everyone has had the opportunity to study this in depth. I will continue to point out errors where I see them. And you, I'm sure, and others, will continue to challenge me to remain accurate.
Anonymous
December 13, 2007
The last week has seen some interesting discussions and useful how-to posts on Open XML blogs ... Three
Anonymous
December 13, 2007
Brian Jones blogged recently about the latest round of proposed changes to the Open XML standard. If
Anonymous
December 13, 2007
Brian Jones blogged recently about the latest round of proposed changes to the Open XML standard. If
Anonymous
December 13, 2007
Robertlilly, "The transition from Microsoft's defacto .doc format to a Microsoft defacto XML .docx format is just about that, nothing more and nothing less." Seriously – has this first dawned upon you now? If you think that the fine folks at IBM, Sun, Novell etc have thought for one second about “the little guy”, I am afraid that you are sadly mistaken. ODF has one single purpose: to be able to tap into the Microsoft Office install base. For years the competing Office application vendors have tried to break the dominant position of Microsoft on desktop office applications – but with little luck. They finally did the only reasonable thing and worked together to create a competing format. Microsoft and their opponents have just chosen different way to preserve their revenue streams – and naturally you might like one more than the other. This reason for IBM releasing their Symphony suite as free is not to make you happy. It is to spread the usage of ODF in the market place – and by that create a market for their IBM-hub focused primarily on ODF. However – if you are so, pardon my choice of words, naïve to think that ODF has been created for “the community”, I’ve got some emails from some guys in Nigeria, that I’d like to send you :o). Now, what the ODF-guys have brilliantly done is to round up the entire OSS-world in support of ODF, but seriously, guys, it’s not about you … it’s about them. Whenever I hear someone talking about “interoperability-problems with OOXML”, “lack of transparency” and “platform-dependant issues”, for my inner eye I always picture me Rob sitting behind the curtain in his puppet-theatre, diabolically laughing: “Dance, puppets ... dance!!!”. All the best, :o) /Jesper
Anonymous
December 13, 2007
The comment has been removed
Anonymous
December 13, 2007
Mike, "You see no difference between arguing your case, and packing committees. Between lobbying and vote rigging?" Yes - and you are perfectly right. It is clear that there is no doubt that IBM has rallyed up their allies and made them join the NBs in order for them being able to carrying out their DOS-attack on the JTC1-process. It is clear that the IBM attack on DIS 29500 has had three fronts through the process:

"OSS-community on steoroids"
Flooding the NBs with an insane amount of irrellevant comments (and some good ones too, btw)
Packing the NBs with their allies in order to reach deadlocks in the process with the sole purpose of prolonging any decisions. Sadly, I think they have succeeded on all three acounts. /Jesper

Anonymous
December 13, 2007
The comment has been removed
Anonymous
December 14, 2007
We have built a wordML to HTML transform and while I appreciate the XMl out of Word I do not appreciate the need to understand the logic that Word uses to interpret the XML. A perfect example is the way Word exports it's paragraph borders. To read and understand this XML you need to know Word's logic when it imports wordML and draws the borders. The wordML is not what you think it is. How does this make it an open standard if the XML is not as straight forward as possible? <wx:pBdrGroup> <wx:borders> <wx:top wx:val="solid" wx:bdrwidth="60" wx:space="10" wx:color="auto"/> <wx:left wx:val="solid" wx:bdrwidth="60" wx:space="10" wx:color="auto"/> <wx:bottom wx:val="solid" wx:bdrwidth="60" wx:space="10" wx:color="auto"/> <wx:right wx:val="solid" wx:bdrwidth="60" wx:space="10" wx:color="auto"/> </wx:borders> <wx:shd wx:bgcolor="FFCC99"/> <w:p> <w:pPr> <w:pBdr> <w:top w:val="single" w:sz="24" wx:bdrwidth="60" w:space="10" w:color="auto"/> <w:bottom w:val="single" w:sz="24" wx:bdrwidth="60" w:space="10" w:color="auto"/> <w:between w:val="single" w:sz="8" wx:bdrwidth="20" w:space="10" w:color="auto"/> </w:pBdr> <w:shd w:val="clear" w:color="auto" w:fill="FFCC99"/> </w:pPr> <w:r> <w:t>Multiple paragraphs with a top and bottom border</w:t> </w:r> </w:p> <w:p> <w:pPr> <w:pBdr> <w:top w:val="single" w:sz="24" wx:bdrwidth="60" w:space="10" w:color="auto"/> <w:bottom w:val="single" w:sz="24" wx:bdrwidth="60" w:space="10" w:color="auto"/> <w:between w:val="single" w:sz="8" wx:bdrwidth="20" w:space="10" w:color="auto"/> </w:pBdr> <w:shd w:val="clear" w:color="auto" w:fill="FFCC99"/> </w:pPr> <w:r> <w:t>Paragraph</w:t> </w:r> </w:p> <w:p> <w:pPr> <w:pBdr> <w:top w:val="single" w:sz="24" wx:bdrwidth="60" w:space="10" w:color="auto"/> <w:bottom w:val="single" w:sz="24" wx:bdrwidth="60" w:space="10" w:color="auto"/> <w:between w:val="single" w:sz="8" wx:bdrwidth="20" w:space="10" w:color="auto"/> </w:pBdr> <w:shd w:val="clear" w:color="auto" w:fill="FFCC99"/> </w:pPr> <w:r> <w:t>Paragraph</w:t> </w:r> </w:p> </wx:pBdrGroup> The other problem with Word is the inconsistent results in the wordML as the round of edit cycles increases (missing elements to help determine font size, missing font information, etc). I have plenty of examples. My guess is that this problem is with the core application and people working around problems in the code base instead of properly fixing the code base. The XML is only as good as the in memory DOM structure. The market will start to see these issues and decide which open format they will adopt.
Anonymous
December 14, 2007
@Mark Baird. You dropped some reformatted XML in your post but you have not actually explained what is actually wrong with it or the way Word interprestes it.
Anonymous
December 14, 2007
Mark, you ask "How does this make it an open standard if the XML is not as straight forward as possible?" There's nothing wrong with simplicity, unless it interferes with the prime design intent of something. So, don't forget that the design intent of OOXML is to faithfully represent the contents of existing billions of Office documents out there. Although I have not looked at your example, my comment is the usual answer to questions like "Why does OOXML do things a certain way?".
Anonymous
December 14, 2007
Rob Weir continues to avoid the issues I raise to him. He now seems to admit that ODF 1.0 is full of holes (but says that's no reason to hold OOXML to that same low standard), while at the same time fails to address the fact that IBM is lobbying governments to standardize on ODF 1.0 by misleading them into thinking that that standard is sufficient for their needs. This guy is unbelievable (in more ways than one).
Anonymous
December 15, 2007
Who cares about the thoughts of a person that works for CompTIA's lobbying arm?
Anonymous
December 15, 2007
omz, >Jesper "Fud" Stocholm Well ... I always like it when someone goes after me and not my words - it usually means that I'm doing something right. :o)
Anonymous
December 18, 2007
Most of the issues in the ODF specification listed in the linked official report are typos or bad grammar where the meaning is still clear. Certainly worth fixing, but nothing critical. OOXML has worse issues, and leaving them to a later version means that we'll be stuck with them forever. (Incidentally, the reason ODF doesn't specify spreadsheet formulas is that doing it right is major task in itself due to widespread dodginess in existing implementations. The only reason Microsoft could include them in OOXML is that they basically just documented whatever Excel did, and this is wrong in various cases. I believe OASIS are currently working on a formula standard for ODF that balances backwards compatibility and mathematical correctness. In fact, Wikipedia reckons that they got their first draft out before Microsoft released the formula specifications part of the OOXML specs.)
Anonymous
December 21, 2007
The comment has been removed
Anonymous
December 21, 2007
The comment has been removed
Anonymous
December 26, 2007
First of all Merry Christmas to everyone who reads this blog and happy upcoming New 2008 from me and
Anonymous
December 29, 2007
First of all Merry Christmas to everyone who reads this blog and happy upcoming New 2008 from me and

Partager via

Over halfway there… including some positive changes to the Open XML standard

Comments

Ressources supplémentaires