다음을 통해 공유

Specifying the document settings

  • 아티클

Earlier today I got an e-mail from Max asking if I could help clarify the section of the specification that deals with compatibility settings. Max was reading a blog post from IBM, and was hoping that I could respond with my point of view. Here's the original message from Max:

Hi,

I read this entry from Rob Weir: https://www.robweir.com/blog/2006/01/how-to-hire-guillaume-portes.html about specific properties inside Open XML, e.g. "useWord97LineBreakRules".

He makes the point how this can be an open format, when the format is documented, but certain properties are not, so in this example, nobody besides MS knows how these specific line breaking rules look like.

It would be great if you could comment your point of view on these issues as an response or on your blog.

Best regards

Max

This is a great question, and one that on the surface seems to have an obvious answer. But, similar to the spreadsheet date issues that we discussed towards the end of last year, the approach taken for compatibility settings was done to allow for the most interoperable format possible without negatively impacting the average end user. Let's explore this a bit more.

Leaving things out of the spec isn't the solution

If you look at section 2.15 in part 4 of the spec, you'll see that there are almost 400 pages of documentation covering 206 elements. I still remember when we first started the documentation of that section. We knew it would be tedious, but the more annoying part was that a good portion of it was for legacy functionality that we would have much rather just left out of the spec. In fact, in Word 2007, when you take a .doc file and upgrade it to .docx we ask you if we can do a full upgrade so that all of those legacy settings are removed.

Unfortunately for us, there was a legacy base of billions of documents out there, and many of them had one or more of these settings. For the same reason we had to give the user the option of doing a full upgrade to remove the legacy settings rather than just doing it automatically, we had to include it in the file format. So rather than just trying to sweep it under the carpet, we embarked on investigating and trying to understand as much as we could about what each of those legacy settings meant.

No requirement for conformance

For the most part, no one building a solution that reads from the format or writes to the format will care to deal with that part of the spec. It doesn't have a significant impact in the behavior of the documents, and as I already mentioned we actually try to get the user to upgrade and turn these settings off whenever we can.

If you look at the first part of the compat settings section (2.15.3) you'll see that we tried to make it as clear as possible that implementation of these settings is completely optional. If your customers really care about it and want you to implement it, then you'll need to do so, and the spec defines how you should represent that setting. Here's the blurb from the spec that tries to make this very clear:

It is important to note that all compatibility settings are optional in nature - applications may freely ignore all behaviors described within this section and these settings should not be added unless compatibility is specifically needed in one or more cases. The compatibility settings are provided for backward compatibility with documents created in legacy applications. As such, a number of the settings reference specific applications and specific versions of those applications. This is solely for backward compatibility reasons, and any of those settings are ignorable.

"Use OpenOffice.org 1.1 line spacing"

Since the folks pointing out this issue are extreme ODF proponents (which clearly shapes their agenda), it's worthwhile looking into whether or not there is a similar issue with the ODF spec. It's actually a great example of the difference between the two specs and the approaches the two groups took when defining the formats. ODF took the approach of just leaving it all unspecified. This is a similar approach that has been taken for a number of things (like spreadsheet functions, etc.).

For example, in OpenOffice, there is a compatibility option called: "Use OpenOffice.org 1.1 line spacing", that when saved out into the format is defined as follows:

<config:config-item config:name="UseFormerLineSpacing" config:type="boolean">false</config:config-item>

That's a bit cryptic isn't it? Unfortunately there is nothing in the ODF spec that explains what that means. It's left undefined. That's probably not as big of a deal for a setting like this, since it talks about using layout from a specific application, but none of the settings are defined in the spec. Other settings a bit more important to the actual display of a document that OpenOffice outputs but aren't defined at all in the spec are:

  • PrintTables
  • LoadReadonly
  • OutlineLevelYieldsNumbering
  • TableRowKeep
  • CharacterCompressionType

Those are just a few I noticed in a blank document I saved out today.

Will there eventually be a new standard within the standard?

This is the approach that was taken for all configuration settings. There is no mention in the standard of how to name these things or how two applications should interoperate. In the blank document I saved out I got a settings file that looks something like this:

<office:document-settings xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0" xmlns:xlink="https://www.w3.org/1999/xlink" xmlns:config="urn:oasis:names:tc:opendocument:xmlns:config:1.0" xmlns:ooo="https://openoffice.org/2004/office" office:version="1.0">

<office:settings>

<config:config-item-set config:name="ooo:view-settings">

<config:config-item config:name="ViewAreaTop" config:type="int">0</config:config-item>

<config:config-item config:name="ViewAreaLeft" config:type="int">0</config:config-item>

<config:config-item config:name="ViewAreaWidth" config:type="int">30032</config:config-item>

<config:config-item config:name="ViewAreaHeight" config:type="int">17570</config:config-item>

<config:config-item config:name="ShowRedlineChanges" config:type="boolean">true</config:config-item>

<config:config-item config:name="InBrowseMode" config:type="boolean">false</config:config-item>

<config:config-item-map-indexed config:name="Views">

<config:config-item-map-entry>

<config:config-item config:name="ViewId" config:type="string">view2</config:config-item>

<config:config-item config:name="ViewLeft" config:type="int">3708</config:config-item>

<config:config-item config:name="ViewTop" config:type="int">3002</config:config-item>

<config:config-item config:name="VisibleLeft" config:type="int">0</config:config-item>

<config:config-item config:name="VisibleTop" config:type="int">0</config:config-item>

<config:config-item config:name="VisibleRight" config:type="int">30030</config:config-item>

<config:config-item config:name="VisibleBottom" config:type="int">17568</config:config-item>

<config:config-item config:name="ZoomType" config:type="short">0</config:config-item>

<config:config-item config:name="ZoomFactor" config:type="short">100</config:config-item>

<config:config-item config:name="IsSelectedFrame" config:type="boolean">false</config:config-item>

</config:config-item-map-entry>

</config:config-item-map-indexed>

</config:config-item-set>

<config:config-item-set config:name="ooo:configuration-settings">

<config:config-item config:name="AddParaTableSpacing" config:type="boolean">true</config:config-item>

<config:config-item config:name="PrintReversed" config:type="boolean">false</config:config-item>

<config:config-item config:name="OutlineLevelYieldsNumbering" config:type="boolean">false</config:config-item>

<config:config-item config:name="LinkUpdateMode" config:type="short">1</config:config-item>

<config:config-item config:name="PrintEmptyPages" config:type="boolean">true</config:config-item>

<config:config-item config:name="IgnoreFirstLineIndentInNumbering" config:type="boolean">false</config:config-item>

<config:config-item config:name="CharacterCompressionType" config:type="short">0</config:config-item>

<config:config-item config:name="PrintSingleJobs" config:type="boolean">false</config:config-item>

<config:config-item config:name="UpdateFromTemplate" config:type="boolean">false</config:config-item>

<config:config-item config:name="PrintPaperFromSetup" config:type="boolean">false</config:config-item>

<config:config-item config:name="AddFrameOffsets" config:type="boolean">false</config:config-item>

<config:config-item config:name="PrintLeftPages" config:type="boolean">true</config:config-item>

<config:config-item config:name="RedlineProtectionKey" config:type="base64Binary"/>

<config:config-item config:name="PrintTables" config:type="boolean">true</config:config-item>

<config:config-item config:name="ChartAutoUpdate" config:type="boolean">true</config:config-item>

<config:config-item config:name="PrintControls" config:type="boolean">true</config:config-item>

<config:config-item config:name="PrinterSetup" config:type="base64Binary"/>

<config:config-item config:name="IgnoreTabsAndBlanksForLineCalculation" config:type="boolean">false</config:config-item>

<config:config-item config:name="PrintAnnotationMode" config:type="short">0</config:config-item>

<config:config-item config:name="LoadReadonly" config:type="boolean">false</config:config-item>

<config:config-item config:name="AddParaSpacingToTableCells" config:type="boolean">true</config:config-item>

<config:config-item config:name="AddExternalLeading" config:type="boolean">true</config:config-item>

<config:config-item config:name="ApplyUserData" config:type="boolean">true</config:config-item>

<config:config-item config:name="FieldAutoUpdate" config:type="boolean">true</config:config-item>

<config:config-item config:name="SaveVersionOnClose" config:type="boolean">false</config:config-item>

<config:config-item config:name="SaveGlobalDocumentLinks" config:type="boolean">false</config:config-item>

<config:config-item config:name="IsKernAsianPunctuation" config:type="boolean">false</config:config-item>

<config:config-item config:name="AlignTabStopPosition" config:type="boolean">true</config:config-item>

<config:config-item config:name="ClipAsCharacterAnchoredWriterFlyFrames" config:type="boolean">false</config:config-item>

<config:config-item config:name="CurrentDatabaseDataSource" config:type="string"/>

<config:config-item config:name="DoNotCaptureDrawObjsOnPage" config:type="boolean">false</config:config-item>

<config:config-item config:name="TableRowKeep" config:type="boolean">false</config:config-item>

<config:config-item config:name="PrinterName" config:type="string"/>

<config:config-item config:name="PrintFaxName" config:type="string"/>

<config:config-item config:name="ConsiderTextWrapOnObjPos" config:type="boolean">false</config:config-item>

<config:config-item config:name="PrintRightPages" config:type="boolean">true</config:config-item>

<config:config-item config:name="IsLabelDocument" config:type="boolean">false</config:config-item>

<config:config-item config:name="UseFormerLineSpacing" config:type="boolean">false</config:config-item>

<config:config-item config:name="AddParaTableSpacingAtStart" config:type="boolean">true</config:config-item>

<config:config-item config:name="UseFormerTextWrapping" config:type="boolean">false</config:config-item>

<config:config-item config:name="DoNotResetParaAttrsForNumFont" config:type="boolean">false</config:config-item>

<config:config-item config:name="PrintProspect" config:type="boolean">false</config:config-item>

<config:config-item config:name="PrintGraphics" config:type="boolean">true</config:config-item>

<config:config-item config:name="AllowPrintJobCancel" config:type="boolean">true</config:config-item>

<config:config-item config:name="CurrentDatabaseCommandType" config:type="int">0</config:config-item>

<config:config-item config:name="DoNotJustifyLinesWithManualBreak" config:type="boolean">false</config:config-item>

<config:config-item config:name="UseFormerObjectPositioning" config:type="boolean">false</config:config-item>

<config:config-item config:name="PrinterIndependentLayout" config:type="string">high-resolution</config:config-item>

<config:config-item config:name="UseOldNumbering" config:type="boolean">false</config:config-item>

<config:config-item config:name="PrintPageBackground" config:type="boolean">true</config:config-item>

<config:config-item config:name="CurrentDatabaseCommand" config:type="string"/>

<config:config-item config:name="PrintDrawings" config:type="boolean">true</config:config-item>

<config:config-item config:name="PrintBlackFonts" config:type="boolean">false</config:config-item>

</config:config-item-set>

</office:settings>

</office:document-settings>

So what part of this is defined in the ODF spec? Well all of the elements are defined, but the problem is that there are only 4 elements used. The actual data can't be determined by the name of the element, but rather the value of the attribute "config:name".

None of those values are defined in the specification though, so there is no way for two applications that follow the spec to share any of these properties without the two applications working together to define a completely new standard within the standard.

Do you want to remove them from the spec?

I guess the question is whether or not folks would rather just see section 2.15 of the spec removed and take an approach similar to ODF. I don't see how that would help interoperability in any way though. Sure it makes the spec smaller, but does that really help? Does it make it easier to move files from one application to another?

-Brian

Comments

  • Anonymous
    January 10, 2007
    I must declare that I haven't written any standards before. One reason I read your's and Weir's blog is because I want to understand the difference between the two document formats. I like both blogs, minus the increasingly hostile nature which I detected lately. I haven't read either Open XML or ODF specs. Weir made his argument by quoting Open XML specification, which is important and I hope you will quote the specific ODF specification (section/paragraph at the very least). Just because OpenOffice.org writes out xml elements does not mean the xml element makes it into the ODF format. Without quote from specific ODF section it does it does mean you did not present your arguments in a as strong as possible light. Rob Weir's original post argues that Open XML specs, not MS or others implementation of Open XML, have xml elements that are clearly specific to legacy version of MS Office and they should not be there. This increases the need to quote from ODF in any counter-argument. Moreover, most of the config:name (some listed below) are rather obvious, especially if you take into account config:type ZoomFactor IgnoreTabsAndBlanksForLineCalculation ChartAutoUpdate PrintGraphics Another point is simply because some of the config:name looks cryptic does not mean they are not defined properly. To do so you will need to show that the specification did not define them. I know showing something is not there is not easy. However, if you say that section A.B.C mention "ViewAreaTop" but you cannot find anything in that section that defines what it is, most people, including me, will be satisfied that you made a reasonable effort and take your word at that, unless ODF proponent prove it to the contrary. ODF proponent always argues that Open XML choice of names/value are cryptic. Hence, to show that they have cryptic names/values do score points for OpenXML. Some of Weir's argument do betray how he thinks legacy issue should be handled. See http://www.robweir.com/blog/2006/01/how-to-hire-guillaume-portes.html#6342215969521370348 One thing that he is arguing constantly is MS Office is likely to be the only one supporting the full specs. This argument is important because Open XML proponent has always said that full "backward" fidelity (not compatibility) by ALL application is the aim of Open XML specs and they therefore they are merely holding Open XML proponent to the standard they specified.

  • Anonymous
    January 10, 2007
    I can seee that the approach by OpenOffice in creating config items that cannot be interpreted makes it difficult as well to interprete ODF document. The config item approach seems simple and easy to use. I like that simple idea. However when I meet any such a config item it seems impossible to tell wheater it is a depreciated feature or a new feature. Also when a multitude of application start creating their own ODF files there seems a big risk of naming different items with the same name which in some cases might lead to strange unodcumented behaviour. I wish for instance that the OpenOffice programmers would have added an id to the config items so in stead of PrintGraphics something like OpenOffice_PrintGraphics but the better way would have been that the config-items would have had a property identifying the creator of the particular item. Something like: Config:config_origin="OpenOffice 2.0". and mayby an optional config status config:config_status="depreciated"

  • Anonymous
    January 10, 2007
    in my opinion, if you put something in a specification, you must "specificate it". So, this autoSpaceLikeWord95-footnoteLayoutLikeWW8 -mwSmallCaps-shapeLayoutLikeWW8 -useWord2002TableStyleRules-useWord97LineBreakRules -wpJustification-etc thing is simply indefendible.

  • Anonymous
    January 10, 2007
    Sinleeh: I suggest Brian to quote the whole 700+ pages of ODF specs to convince you that what he mentions really doesn't appear in the spec. ;-) hAl: I agree with you, and I suggest to add a "namespace" attribute (to identify the origin of the config element), what would more conform to XML usage.

  • Anonymous
    January 10, 2007
    The comment has been removed

  • Anonymous
    January 10, 2007
    Brian : I did a quick search for config-item in  ODF spec 1st May 2005. It appears in section 2.4.2, pg 48. The section is part of "Section 2.4 Application Settings". I did not read the specs, but it sounds to me it means config-items are used to hold application specific information, such as placement of menubars etc. It is extremely likely that the config-items you quoted in this blog post falls into this category. If used as "application settings", nobody will expects these settings to be portable, nor is it designed to be. hAl: it looks like "config-item" are designed to be used as a key-value map. HTH

  • Anonymous
    January 10, 2007
    Thanks for pointing out those omissions, Brian. I hadn't read the ODF standard. Apparently, neither have some of its staunchest supporters. Still, a clear answer would be appreciated: are all of the compatibility settings deprecated? This information is not in the OpenXML specification.

  • Anonymous
    January 10, 2007
    True, I missed this "name" attribute in the config set (it is not very well chosen, as a name rather refers to something private, an internal name used to identify the set among others, and not to a shared identifier...). To answer your initial question: personnaly I think that unspecified items should not appear in the specification of a standard. I agree that if it's the only remaining issue with Open XML, it's a rather good sign. But I believe ISO will require those elements to be removed from the spec before accepting it. And that should not be a real issue for Microsoft (or ECMA)...

  • Anonymous
    January 10, 2007
    The comment has been removed

  • Anonymous
    January 10, 2007
    Stephan, how is this any different from ODF documents with application specific config settings?

  • Anonymous
    January 11, 2007
    Stefan Wenig, The differences are (1)Whether it affects the presentation/content of the document, e.g., italics in the wrong places etc. Serious one as it affects the interpretation of the document by machines and humans (2)Whether it is just an indication to the application on how to display the non-important and non-portable things such as location of menu bars etc. Not important and is usually ignore. For example, you will want to ignore Photoshop's menubar setting if you are simply displaying a photoshop picture in your word document. Interesting questions and certainly worth debating. However comparing the two posts looks like comparing oranges with apples to me.

  • Anonymous
    January 11, 2007
    The key here is that MSOOXML claims: "[O]pening Up Billions of Documents ... Thanks to the depth of the technical resources the TC45 created, the Open XML standard covers the full set of features used in the existing corpus of billions of documents..." ( from http://www.ecma-international.org/news/PressReleases/PR_TC45_Dec2006.htm ) So, this autoSpaceLikeWord95-footnoteLayoutLikeWW8-mwSmallCaps-shapeLayoutLikeWW8-useWord2002TableStyleRules-useWord97LineBreakRules thing becomes important. IMHO, if they are in the "standard", they must be clearly and completely specificated, or taken away. Does MS knows the word "ethic" ?

  • Anonymous
    January 11, 2007
    The comment has been removed

  • Anonymous
    January 11, 2007
    @marc Standards often are filled with dpreciated features that are not specified in detail. Even a lot of ISO standards have those kind of depreciated features. In thos case the only reason for the existance of those features is compatibility for older office documents. But not even MS Office 2007 supports all of those depreciated features. However they are there so that you can A) recognize that the document might not render the same as the original B) to see what might be the application that could recreate the original rendering. I would for instance use those features to recognize possible problems when doing a mass conversion of old Office binary files. Those kind of compatibility issues would have been extremly hard to recognize within binary files. But now after a conversion I can easily create a search program to verify if my older document contain compatibility issues which might make them unfit for use in newer application an if nescesary even correct those issues manually. Especially important when faced with either libaries or legal documents conversions. Especially with these kind of rendering issues it it likely to be impossible to exactly recreate the original documents without using the original applications. MS Office does take some of the issues into next verions for compatibility reasons but leaves out others.

  • Anonymous
    January 11, 2007
    Dear hAl, Your reply to marc is the by far the best response I see to having all the "deprecated" office 95-2003 features. Congratulations. I agree those features can be used in the way you described and it will definitely be very useful for third party apps that cannot render the documents properly to flag it for manual intervention. We still need to discuss what these "deprecated" functions impacts a non-MS applications who sets out to faithfully maintain fidelity with older MSOffice documents. Is the standard, as it stands good enough? As other posters and I had pointed out, the reason we hold OOXML to this standard is because it is "the aim" of the standard from day one. And being a standard, we must expects third party, namely non-MS application to be able to achieve this aim.

  • Anonymous
    January 12, 2007
    The comment has been removed

  • Anonymous
    January 13, 2007
    Thanks again for all the comments everyone. Clearly, there are areas that we could look into improving for the next version of the spec. The ODF folks left out huge pieces of the specification. Our approach was to instead document everything. Some places could probably use a bit more information, and maybe TC45 will decide that those should be improved in the next version. Remember though that the large majority of these settings are also used in ODF documents. The problem is that they are all application specific an left undefined in the actual specification. That means that if you follow the ISO ODF standard, there is no interoperability to speak of in these areas. The Open XML spec on the other hand clearly specifies what they are to be called, and how they behave. There are a handful that could probably use better descriptions, but those are clearly in the minority. -Brian

  • Anonymous
    January 14, 2007
    sinleeh, well argued, but what you say simply does not apply to all settings in the fragment brian posted. it's ok for things like "ZoomFactor" to be ignored in other apps, but look at things like "DoNotJustifyLinesWithManualBreak" or  "UseFormerObjectPositioning". so i think my question is still valid.

  • Anonymous
    January 14, 2007
    I'm not a proponent of either standard, but the difference seems clear to me.  The fact that the XML elements you quote are nested within [config:config-item-set config:name="ooo:view-settings"] and [config:config-item-set config:name="ooo:configuration-settings"] tags surely shows that these are application-specific settings that do not affect the document's contents or layout, e.g. zoom factor and print settings are purely specific to OpenOffice.org. However, "shapeLayoutLikeWW8" and similar tags do in fact effect the layout of the document itself. Now I hear the argument that these elements in the OOXML spec are optional for software implementing the spec, but isn't backwards compatibility really the whole reason behind the OOXML spec in the first place? It's nice that Word 2007 tries to get users to convert from these legacy features, so surely this means Word must have been developed with a generic or flexible enough layout model that allows "useWord2002TableStyleRules" to be converted and marked up in OOXML? So, in that case, what's the problem in specifying in the OOXML spec what the transforms to be applied are? Regards, Chris

  • Anonymous
    January 14, 2007
    Christopher, just look at the settings. The ODF settings absolutely affect the layout. They just decided to try and sweep them under the carpet by using the OO namespace, and not documenting them in the spec. -Brian

  • Anonymous
    January 15, 2007
    The comment has been removed

  • Anonymous
    January 15, 2007
    sinleh, i just browsed through the settings list that brian posted, and i can't help but think that this is a classical example of assuming the worst about msft and the best about everyone else - as long as they are up against msft. many of them are probably just settings that don't really affect interoperability and layout, but i don't think all of them are. i may be wrong, but then i think that rob weir will use just about anything against openxml that he can. take this posting: http://www.robweir.com/blog/2006/07/lost-in-translation.html he's reading the scope for the prototype and jumping to conclusions about what's intended to be in the final thing that don't make any sense. and he has never approved my comment about this obvious mistake. he's a smart guy, but i don't see why he should be any more trustworthy than anyone from msft.

  • Anonymous
    January 15, 2007
    Dear Stefen Wenig, [On Rob Weir will use just about anything against open xml that he can) Yes, I agree he will. I try not to, but seems to be falling into the same trap  often myself. I am obviously not aware of Rob Weir disapproving comments that he don't like, but would not be surprise about it coz there is a moderation policy on his blog. Weir is guilty on discussing only the sections he wants to discuss, but so does Brian. There is their rights as it is their blogs. To censor comments is arguably their rights as well. However, I do not think it is ethical for anyone to do this. Personally, I see we have two opposite camp here: this blog and Weir's blog. that is what make me read both blogs. I never accept what both parties said as absolute truth. I find that I can learn a lot about XML design by participating in discussions on both blogs. One potential criticism on Brian's posts in general is that he do not quote from the ODF standard, unlike Weir. This give me the impression that Brian did not bother to refer to the ODF specs at all when posting. Rightly or wrongly, Weir's reference to OOXML specs lend his argument credibility. "Assuming the worst about MSFT and the best about everyone else" is one of my weakness. Something I am trying very hard to eradicate. That bias is not good in any discussion. From Weir's original post, this counter-post and his rebuttal, it is clear that both OOXML and ODF in one way or another contains settings about applications, including legacy applications, in their zip bundle. The question of interests is where it occurs, and how does it impact applications. Some of these settings are not properly documented in the specs and may be we should not be too crossed if they are not. It is the designers' choice. The only thing we can discuss is whether the designers achieve their goals and the impact/merits of their design decisions. In both OOXML and ODF, interoperability. In OOXML, MS stated goal of faithfully reproducing legacy documents (and whether third party who wants to do so can do it with reasonable effort) and in ODF, whether does it successfully support cross-platform  / multi-vendors and whether some missing parts, i.e. spreadsheet formulas is as bad as the opposition claims. There are other goals that we can discuss as we go along and as both camps starts the discussions.

  • Anonymous
    January 15, 2007
    regarding Weir's and Brian blogs, i have to say that in general i don't agree with Brian counter-arguments ( his words sound like PR blah blah ), but i congratulate his openness with the comments, because he doesn't delete anything. Rob, learn from Brian and let the people express disagree !! greetings to Brian.

  • Anonymous
    January 15, 2007
    sinleeh, i agree quite a lot with your statements. work should focus on finding actual problems and getting them solved. i think it's unfortunate that the ODF camp is attacking open xml so hard and basically claiming that it has no right to exist as a standard. (in the beginning they even claimed that it has no right to exist at all, but they obviously have learned that this is not a very promising strategy...) so, yes, critisism is ok. it's not always right, though. further examination may lead to the conclusion, that absolutely nobody is interested in implementing those legacy settings of open xml. then again, the opposite may be true. but come on, having the spreadsheet formulas not documented and critizising the other party for some obsure legacy stuff... (and look at the conclusions rob draws, he's not just pointing out the facts!) besides, i don't look rob's dismissive tone. as someone who disagrees with him a lot, i can't help feeling pretty patronized. go figure, i got reasons for my opinion too.

  • Anonymous
    January 17, 2007
    sinleeh, "One potential criticism on Brian's posts in general is that he do not quote from the ODF standard, unlike Weir." That is exactly the point - Brian cannot quote from the ODF standard because these elements are not documented there.