a 'mooh' point

clearly an IBM drone

Versioning of OOXML (thank you for all the fish)

One of the most pressing matters we had to deal with in Okinawa was a question raised by quite a few people including members of the national body of Switzerland as well as hAl on the blogs of Alex Brown, Doug Mahugh and yours truly:

How can you tell if a document is generated using the original set of schemas or the new (improved) ones?

The truth is: you can’t.

Well, at least not at the moment. You can get a hint from sniffing at various parts of the document, but there is no definitive way to do it. We all agreed that we had to come up with a solution, and we discussed (at length in session as well as during breaks, dinners and sight-seeing) what to do.

Roughly speaking, there are a few ways we could do it, including

  • Changing the namespace-name of the schemas
  • Expand the conformance attribute to indicate version of OOXML
  • Adding an optional version attribute to the root elements of the documents (WordpressingML, SpreadsheetML and PresentationML) defaulting to the original edition of  ECMA-376.

Version attribute

Let me start with the last option, since it is the easiest one to explain and understand.

ODF has a “version”-attribute in the root element of ODF-documents. It is defined in the urn:oasis:names:tc:opendocument:xmlns:office:1.0-namespace, so when creating e.g. an ODF spreadsheet using OOo 3, you will see the following xml-fragment:

[code:xml]<?xml version="1.0" encoding="UTF-8"?>
  xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0" (...)

The above would tell you to use version 1.2 of the ODF-spec – currently being drafted by OASIS.

We could do a similar thing with OOXML, that is, having an optional version-attribute with the version number of the applied flavor of OOXML. This approach would have some clear advantages. First and foremost it would allow all the existing applications supporting OOXML to do absolutely nothing to their existing code base to continue to be able to read and process OOXML-files in ECMA-376 1st Ed format. It would also enable them to use any existing schema-validation of content and all existing files in ECMA-376 would still be perfectly valid.

Expanding the conformance attribute

Another thing to do would be to expand the new conformance attribute. At the BRM in Geneva a new conformance attribute was added to the root elements to display to which version of OOXML the document conforms. You will perhaps recognize this XML-fragment
[code:xml]<w:document conformance=”strict”>
We could also use this attribute and add version information to it. A way to do it would be
[code:xml]<w:document conformance=”transitional-1.0”>
for the ECMA-376 1st Ed and something else for any subsequent versions.

Fixing or solving?

The problem with the two alternatives mentioned above is that they provide an immediate fix, but they are in no way panaceas for the issue of versioning. In Geneva we split up OOXML into 4 distinct parts and tried the best we could to make sure, that they were “islands” within themselves. So in the original submission’s Part 2 dealing with OPC, there were dependencies to WordPressingML (AFAIK) and these were removed. The result is that you can now refer to ISO/IEC 29500-2 should you in your implementation need a packaging format where OPC suits your needs. The basic idea was exactly this; to provide a way for other standards to be able to “plug in” to OOXML and reuse specific parts of it.

The two fixes described above provide a fix for the problem with versioning of “the document stuff”; text documents, spreadsheets and presentations – but they do nothing for Part 2 and Part 3 (under the assumption that Part 4 will not change). The trouble is - this is not only a theoretical problem. ECMA TC46 working with XPS (Xml Paper Specification) has based the package format for XPS on OPC. But it is difficult for them to refer to ISO/IEC 29500-2 OPC since it is not possible to distinguish the namespace name from its predecessor ECMA-376 1st Ed. So unless we figure out a solution, they will have to refer to ECMA-376 1st Ed (and it was my impression that they’d prefer to refer to ISO OPC instead).

This is kind of annoying or maybe even embarrassing. We (the ISO process) chose to split up OOXML to allow reuse – but the first time someone knocks on our door and wishes to do exactly that – we (unless we find a solution to this problem) will have to say: “Well, we didn’t actually mean it”.

Change the namespace-name

An entirely different approach would be to change the namespace name(s) of IS29500. The original names where along the lines of


So an alternative solution would be to change the values of the namespace name. The names above could be changed to

http://schemas.openxmlformats.org/package/ IS29500-2008/relationships

(I would have liked to use colon as seperator between the ISO project number and year, but according to http://www.w3.org/TR/REC-xml/#sec-common-syn, it seems colons are not allowed in namespace names.)

What would be the consequence of this?

The up-side

Basically, changing the namespace name would solve the problem with distinguishing between ECMA-376 1st Ed and IS29500:2008. It would be trivial to distinguish content based on either standard and it would apply to all parts of the specification. Actually, it would apply to all schemas in the specification, so it would enable someone to create a document based on ECMA-376 OPC, IS29500 WordpressingML and ECMA-376 DrawingML (even though this is permitted in the current version of OOXML). It would also give us the chance to have a fresh start with IS29500:2008 and give us a clean slate for our further work.

The down-side

Changing the namespace is sadly not a silver bullet – unfortunately the free lunch comes with nausea as well. The trouble is – by changing the namespace, applications that support ECMA-376 will break if they try to load documents based on IS29500 since the namespace will be foreign to them.

The question is, though: shouldn’t they?

The purpose of XML namespaces are to identify the vocalulary of the elements of an XML-fragment. So the real question could be: are we talking about a new vocabulary when going from ECMA-376 to IS29500:2008? Are the changes from the BRM so drastic that we wouldn’t expect applications supporting ECMA-376 to be able to load documents conforming to IS29500?

Well, it was of importance to ECMA and most of the delegates at the BRM to ensure that whatever we did to change the specification did not render existing nonconformant. We succeeded quite well in doing just this,  so one could argue that the changes were not that big. However, this just concerns the transitional schemas. If you remember, the changes in schema structure were quite big. We divided one big chunk of schemas into two categories, “strict” and “transitional” and I would indeed argue that we changed the vocabulary by doing just that. We changed it from defining a vocabulary with a complete mess of legacy-stuff and new stuff into two separate piles with one “going-forward-vocabulary” and one “going-backwards-vocabulary”. Isn’t that big enough to change the namespace name?

Do it right the first time

At the WG4-meeting I was actually advocating for a simple addition of a version attribute and solve the bigger namespace problem at a later time for a revision of OOXML, but the more I think about it, the more I am convinced this is the wrong way. We are in a position right now where there are no applications out there supporting the full set of IS29500. Not changing the namespace name will not make the problem go away – it will just postpone the issue, and if we wait, the problem will become increasingly bigger as applications will surface with support for IS29500. The problem will be even bigger if you have a long list of supporting applications and not – as now – none a single one.

The more I think about it, the more I am sure the right way to do it is

  1. Add a new version attribute to the root elements defaulting to “1.0” which would be ECMA-376 1st Ed. IS29500:2008 would have version “1.1”.
  2. Change the namespace name for IS29500 in a matter as outlined above.

Vendors in the process of implementing IS29500 will then have to add some code to their application to support this.

But – I am in no way sure I have covered all angles. Am I missing something here?


Comments (21) -

Personally, I do think it makes sense to change the Namespace Name for the strict formats, and the idea of “going-forward-vocabulary” vs “going-backwards-vocabulary” captures the motivation well.

This would offer a good solution to the immediate version problem, and provide a robust and idiomatic mechanism for conveying version information going forward.

Ideally I would not like to see a year embedded in the Namespace Name, as this can give the impression that the format is tied to a particular point in time. ODF has an equivalent nastiness through its embedding of "1.0" in the Name even for later versions of that format.

I would like to see the Namespace Name kept the same for subsequent revisions of the strict schema, and for the version attribute to convey the versioning information - this is a proven approach that has worked well with XSLT. (See http://is.gd/huSf for more on this from me).

On a policy matter, the domains for the current Namespace Names are registered by MSFT. SC 34 standards should use a neutral registrant for these instead. In WG 1 we use the purl.oclc.org domain for this purpose.

There is also the interesting question of whether this kind of change is an amendment to, or a correction of, the Standard. I think that point is arguable.

- Alex.

I think changing the domain in the schema's to purl.oclc.org is terrible.
Better is to ask Microsoft to hand the current domain over to Ecma International.

I find the namespace solution looks only good on paper.
Except for a few almost every application application will support only major versions of a document standard. This will contain a standard set of namespaced schema's.
No application will support a mixed set of namespaces from different major versions because that would cause serious compatibility issues.


No application will support a mixed set of namespaces from different major versions because that would cause serious compatibility issues.

Just to clarify: I am not advocating changing the namspace name for each new version of OOXML. I am advocating changing it now to be able to distinguish between ECMA-376 and IS29500.


I do not believe Ecma International would be an acceptable registrant. PURLs are a solution which gives long-term assurance (http://purl.org/). After much discussion, they are also a settled solution that NBs find acceptable for Namespace Names.

As I see it the Namespace Name has to change at some point, either when 29500 is first revised (policy reasons), or because the "2007" in the URI will get amended (editorial reasons).

It is far better to do this now, before there is any accumulation of IS29500 documents, than to do it later and create a serious legacy document problem, with same-format files having different namespaces.

Users will have complete clarity about which is an International Standard document, and which not. I do not see any downside for users. Am I missing something?

- Alex.

Sould we use PURLs or URNs as namespace names?  DSDL uses PURLs as
namespace names.  I vaguely remember that people wanted to use RDDL
and thus resolvable URIs (as opposed to URNs).  

Jirka Kosek

I think that namespace change is quite radical and I'm not sure if it will be accepted by NBs.

Moreover, elements which are the same in ECMA, Strict and Transitional versions have same semantics, so I don't see need for different namespace.

However having version attribute would be good, so applications can easily distinguish between versions. No version attribute => ECMA version.


Well, http://purl.oclc.org/dsdl/schematron certainly resolves, for example ...


I agree with you about the version attribute. The question remaining would be: how do we make versioning of OPC? Could a solution be to add a version attribute to [Content_Types].xml or the relationship-files?

Jirka Kosek


do we really need to cope with OPC versioning now? I don't think so.

If there will be some backward incompatible changes introduced in future, namespace should be of course changed.

And if OPC really should be versioned then I think that having version.xml part in the root of package will be the best solution. version.xml can then contain only one element with content indicating version used.


do we really need to cope with OPC versioning now? I don't think so.
Well, when dealing with this issue at the meeting in Okinawa, the project editor for XPS (ECMA TC-46) mentioned this as the very first thing.

Wether it is important to us and also a priority is naturally for us to decide, but my reason for mentioning versioning of OPC was just this - that TC46 would like to be able to refer to IS29500:2008-2 (OPC) and has an issue with distinguishing between the to versions of it.



Oh - and from the top of my head, your solution to have a version.xml in the root of the package seems like a nice and balanced way to do it. I have not had time to think about the consequenses for "flat file"-OPC or other "package-less" usages, but I like the idea.

I am personally in favour of the namespace change option.  By the way, I'm an Excel guy, as will become apparent.

Although the opinion seems to be that there are not all that many ECMA-376 files floating around out there, I think there are enough for it to be important. I am not sure how many mass-producing apps are out there, but we have customers that might produce or update thousands of spreadsheets a day.

Multiply that by thousands of customers just for our small company, then add Microsoft's Office 2007 customers. The increased limits in Excel(for the first time in a long time) have made XLSX a very attractive proposition for business users, especially those with high usage of spreadsheets. This would probably yield a large number of XLSX files than the bald customer numbers might suggest.  I also imagine that the ease of implementing Excel export functionality, especially on non-Microsoft platforms, means that more and more software companies, especially in the financial and ERP-like markets are taking the opportunity to  implement it at a much lower cost than was previously the case.

Couple that with a much smaller, but noticeable effect from Excel Services (XLSX required) and you have one good size population of ECMA-376 legacy sitting out there.

To go back to why I am in favour - I think one of the key aspects of interoperability is data quality. If apps written with no knowledge of the future versioning methodology will simply open and attempt to do the best they can with a document that could contain breaking changes, then data could be lost or corrupted in some way.  Very bad, especially in a spreadsheet.

This would reduce confidence in the new version and people would seek the safe haven of the lowest common denominator, ECMA-376. In addition, as far as I can recall, the office 2007 beta used a different namespace before switching to a final for release. This (rightly or wrongly) gave us an impression of what a future version strategy might look like. We liked it back then - clean and predictable, forcing developers into the good habit of identifying all the relevant changes and going through the traditional development and test iterations before releasing new code, which by definition could cope with the old and the new.

Enforcing developers to revisit the code is even more vitally important given some of the issues I have seen with other software reading and writing XLSX.  I will mention no names, but very often Excel is seen as the canonical source of OOXML, not the spec.  In fact, in some cases from the behaviour I have seen, I am not even sure the spec was actually used at all, with developers maybe just repeating their rote behaviour of reverse engineering Excel files.

However, the benefits associated with this approach are only really worth it if there are going to be breaking changes which can affect interoperability, data quality, reliability and so on.  If there are only edge cases produced by changes in the spec, then the cake may not be worth the candle.  I don't know if that's the case, but as I mentioned to someone (you know who!) the other day, the best way to deal with this is by simulation / scenarios.  Mock up documents based on individual spec changes and then test them against existing applications.  See how they react.  Pontificating and theorising on impact to existing applications may lead to the same conclusions, but doing it for real can take less time and is more authoritative.

The sad thing is, this may well all be to an extent moot, unless OOXML includes some hugely compelling features for USERS, rather than developers.  As far as I can see, Office will remain the number one producer and consumer of these files, and the well-known behaviour is that users will most likely save in the lowest version format that can successfully contain the feature set they are using.  This mindset is also propagated by IT departments around the world, who know this is the path of least resistance.

Shawn Villaron

Hi guys,

Great discussion.  Sorry I’m joining late.

I was going over my notes from Okinawa where I had a notation regarding what exactly the “ask” was with this issue ( I hesitate to call it a defect as I understand this is an altogether separate discussion ).  I recall that we talked about methods of versioning the package ( i.e., the container ), versioning the document and even versioning parts.  I believe that the actual “ask” was about versioning the document.  And while I believe there is considerable value in addressing packaging version ( e.g., helping the XPS guys reference OPC ), I’d like to suggest that we keep these issues separate, if only because my personal opinion is that we’d solve them differently.  

I think it’s worth a few moments to talk about the emerging ecosystem around Office Open XML, as I think that how we address this issue could have some serious consequences on this.  One bit of feedback I got in Okinawa was to spend time looking at how various vendors have implemented Office Open XML.  That experimentation over the past few days has really re-enforced the fact that we do have a handful of vendors writing code against this standard.  At the moment, I’ve been experimenting with Apple iWorks, OpenOffice 3.0 and Microsoft Office 2007 SP1 ( the Villaron house is very pro-interoperability; we have them all ).  I know I’ve barely touched the surface here, and I believe we’re getting more vendors supporting this standard all the time.  So I’d respectfully suggest we keep these vendors’ solutions in mind when considering changes to the standard.  

It was also mentioned that perhaps now is the time to act on this issue “before there is any accumulation of IS29500 documents.” [AB]  As I’ve been watching the ecosystem emerge, I’ve been doing some back-of-the-napkin tracking of these documents.  My method isn’t scientific but it’s an easy way for me to see things progress.  My method is simple: I use Google ( disclaimer: I work for Microsoft, so I wanted to track using non-MSFT software ) and do a filetype search.  I look for the number of hits for the following extensions: odt, docx, ods, xlsx, odp and pptx.  I chose the ODF formats as a good baseline to gauge the success of the OOXML formats.  

Running the query tonight gets me the following data:

ODT ................ 119K
DOCX ............... 177K
ODS ................ 26.1K
XLSX ............... 32.7K
ODP ................ 37.5K
PPTX ............... 57.8K

Looking over my data from my previous experiments, the progress tracks like this:

( ODF = ODT + ODS + ODP )

May 23, 2008
... ODF ........ 94K
... OOXML ...... 66.2K

Sept 30, 2008
... ODF ........ 126K
... OOXML ...... 141.3K

Feb 9, 2009
... ODF ........ 182.6K
... OOXML ...... 267.5K

If others have alternative methods to gauge the proliferation of these documents, I’d be interested in improving my own tracking.  Any help here would be greatly appreciated.

And so, like the vendors’ implementations, I’d like us to remember that we’re already in the midst of an accumulation of documents.  Granted, most are likely Ecma 376 documents, but given the differences between Ecma 376 and IS29500, I don’t think we ought to split hairs here.

My last concern regarding the ecosystem is that I think we want to be especially careful about breaking changes, especially those that impact most/all compliant files, given the potential harm that they can have.  I realize that breaking changes are going to happen over the course of the lifetime of the standard.  But I think we’re very early in that lifetime, and our focus should be about establishing a solid baseline from which the ecosystem can grow.  There will be a time to break the file format.  I’m hoping that we can avoid doing that in these early stages.  I realize that this is a tall order, but it’s something I think we should all aim for.

Now to the proposals.  

Looking at the four proposals ( an actual namespace change, adding an optional version attribute, extending the compliance attribute and adding a new version.xml part to OPC ), I’m starting to like the namespace change, especially if we take Alex’ suggestion about making it a strict only change.  My experimentation shows that none of the three implementations I referenced above are writing out strict files.  I haven’t found many strict files on the web either.  At this point I sure don’t feel comfortable saying that no one is generating strict files, but I think we run a much lower risk of causing pain to the ecosystem if we focus this change on strict files.  For me, when I read Alex’ suggestion, I exclaimed “he nailed it!”  So this is a proposal I’d be interested in working with folks on fleshing out the details.  Anyone interested?  I’m particularly interested in learning about PURLs.

To round things out, I looked into the optional version attribute.  Some implementations can handle this; some can’t.  But, again, if we follow Alex’ suggestion and limit this to strict files, I could certainly support that.  

Extending the compliance attribute was something I thought would help, but I wasn’t able to come up with a solution that didn’t seem like a hack.  Was anyone else very successful here?

The version.xml part is a very interesting idea for addressing package versioning.  I don’t get excited about using this to handle document versioning.  

Thanks for reading this far.  As you can tell, I’m really interested in finding a way to address this issue in a way that minimizes its impact on the Office Open XML ecosystem.  If anyone wants to partner up, please let me know.


Shawn Villaron
Group Program Manager, Microsoft Office PowerPoint

Hi, (thanks for pitching in Shawn)

I am operating somewhat in the dark here, not having knowledge of ALL the  changes from ECMA-376 to IS2900.  If anyone has a handy link?

What I do know is ISO 8601 dates in spreadsheets is a breaking change for any existing apps that read / update files. If an app is expecting to consume a serial date but gets an ISO date instead, it's garbage.  I probably have a different perspective from many here, being so Excel focused, but data quality issues in spreadsheets are (I contend) many times worse than getting some paragraph alignment wrong or some other less trivial interop issue.

Our first major release that supported reading OOXML spreadsheets was back in Feb 2006 and we had another in 2008.  We are on a 18-24 month year release cycle, but with a much shorter support window than say, Microsoft has.  That meaning, we are unlikely to want to go and patch a 3 year old product.  In addition, we have found that our products have a very long lifetime.  We still have people using versions from 10 years ago, so no doubt our users will be poising the well with serial dates for many years to come!

As no versioning strategy was in place early on, there was no way to predict how to detect a later version of a file.  I use "file", as both the package and the contents are affected.

So even the strict/transitional option would still allow ISO dates to be written to a document that an ECMA-376 designed app (namely, ours) would most likely happily load and then choke on.

I suppose another way to put it would be that in most cases the harsh namespace change would lead to "old" apps issuing a "Cannot read file" type of error and users contacting the vendor about why that is, is there an update etc rather than unpleasant silent errors that may or may not get found at an early stage of a long business process and the user contacting the vendor and screaming at them, before being told they have to pay to upgrade to a version that supports the "new version of the standard".



I don't want to deny there's an accumulation of .docx, .xlsx (etc) files, which is why I was careful to say there isn't an accumulation of "IS29500" docs. The context of this discussion is, I think, one place where it's more than okay to split hairs! Smile


The changes between Ecma-376 (1st edition) and IS 29500 Transitional are quite minor. The changes between it and IS 29500 Strict are more profound.

So far as I know, there is no convenient guide to these differences -- that delta information remains in the various editing instructions and documents that came out of the BRM, many of which are not public.

- Alex.

Thanks Alex (and Jesper for being such a gracious host!)

That delta information will be critical for publishers of existing apps in the near future.  Maybe it could be included as part of Microsoft's implementation notes, which is a natural place for developers to look.  Obviously other forums for that information exist too, but I don't know offhand what they might be.

As I understand from the spec on the ECMA site, the ISO dates are allowed in transitional too, so that any app writing to transitional could still create a valid document that is unlikely to be read by an app designed against ECMA-376 (1st Edition), which is expecting to parse serial dates.  Do I understand this correctly?

I looked at the schema and it appears that the value element in a spreadsheet cell (the CT_Cell Type) is a string anyway, so the change to ISO8601 was not backed up by schema typing, it's down to the app to parse this out, whether it's a serial date or an ISO 8601.

Not armed with prescience, early adopters are going to be affected by this.  Not being able to read a date from a spreadsheet is not quite minor, well not in my world of QA and development anyway.  This would be a priority 1 bug, "must-fix" before release, in the "Data Corruption" category.

Now, purely by fluke and the good practice of our developers, it MIGHT be that we threw the value at our parsing engine, rather than hardcoding it, which might mean that it will work correctly, even if an 8601 date is encountered "unexpectedly".  I'd say we would probably be in the minority there though, since we have a nice internal text parsing engine just lying around to be piped in to such things.  I'll check into that.

@Shawn, do Microsoft have a "clean room" diff of the changes between versions?


I believe that the differences between the ISO/IEC 29500 transitional schemas
and the DIS 29500 transitional schemas are quite significant, even when we
do not consider schema reorganization (i.e., merging schema files) and
reorganization of common simple types as such differences.

I computed the diff between the latest wml.rnc in Part 4 and my
personal wml.rnc, which is created from wml.xsd in the DIS.
The differences are very significant.  Let me show a few examples.

First, the content of pPr elements now have a new complex type CT_PPrGeneral, which is different from the original type CT_PPr.


w_CT_PPrGeneral =
  element pPrChange { w_CT_PPrChange }?


w_CT_PPr =
  element rPr { w_CT_ParaRPr }?,
  element sectPr { w_CT_SectPr }?,
  element pPrChange { w_CT_PPrChange }?

Permissible values of the simple type ST_Border are quite different.  

>   | string "earth3"
<   | string "tribal1"
<   | string "tribal2"
<   | string "tribal3"
<   | string "tribal4"
<   | string "tribal5"
<   | string "tribal6"
>   | string "triangle1"
>   | string "triangle2"
>   | string "triangleCircle1"
>   | string "triangleCircle2"
>   | string "shapes1"
>   | string "shapes2"
>   | string "custom"

Moreover, two resolutions in reponse to Finish comments allow the "%" character
whenever you specify percent values and the measurement unit (e.g., "cm")
whenever you specify lengths.

I thus believe that we need a mechanism for distinguishing the transitional ISO OOXML documents and the Ecma 1st edition OOXML documents.  If we choose a
new namespace, it should also be used for the class "transitional".

If no descision is made soonish I expect Microsoft will just release a solution of their own in Office 14 and it will be hard to overcome their choice.


If no descision is made soonish I expect Microsoft will just release a solution of their own in Office 14 and it will be hard to overcome their choice.

There is no way this can be decided before the plenary in Prague in late March.

(I'll follow up on the discussions between Shawn and Gareth soon)


So, on my last afternoon before leaving for the WG4-meeting in Prague, I now have a bit of time to ponder over this again.

(why is it always so that time to ponder always appears in the 11th hour?)

We had a lengthy discussion in the Danish NB this week about this very issue, and even though we didn't come to an agreement of what to propose, we "agreed to dissagree" on the matter of "is the namespace change worth the trouble?" I still think the namespace chance is the only right way to solve it - especially given the arguments of Gareth - but we need to make sure, that there is not another, less-devastating solution that solves the problem to the same degree.

And on a side-note: one of the really cool things about OOXML is Part 3, Markup Compatibility and Extensibility. The reason for this part is, to use the words of Microsoft "to allow organisations to innovate" (or something similar like to this). Now, has anyone looked at how using a version attribute (or version.xml-file) will affect MCE-usage? It seems to me that not changing the namespace will make it impossible to use MCE to take advantage of the new stuff in IS29500 in "the comfort of ECMA-376 1st ed").

I will write a bit about this in the airport tomorrow on my way to Prague - if I am not disturbed too much by ... ahem ... "other travellers".


Well, this is an old post but the comments are interesting.  

What is striking for me is that MCE is not applicable to this problem, mainly because subsuming apparently doesn't work.  If I understand the discussion correctly, the IS 29500 strict is subsumed by the IS 29500 transitional, but that doesn't help with ECMA-676 1st edition.

It seems to me that one needs to align IS 29500 with MCE and it would be great if the non-subsumed ECMA 676 1st edition was distinguished.  I can't imagine how this can be accomplished without the IS 29500 namespaces being different.

I am skeptical of version identifiers.  We have them for ODF, they are potentially tightened a little for ODF 1.2, but they simply don't help resolve up-down-level matters because you still have no idea whether the specific document really depends on something that is different between the version it is identified with and other versions.  Implementation behavior around unrecognized versions (i.e., pretend it is what I understand and see what happens) is not helpful either where there are arbitrary breaking changes between default behaviors, for example.

Comments are closed