I enjoy Doug Mahugh’s humour very much. He responds to Alex Brown who recently confirmed “failure”:
We generally don’t publicly discuss features this early in the product development lifecycle, but given the broad interest I’m going to share some of our thinking on Strict support here. We’re doing this to assure everyone involved that we understand – at all levels within Office – the importance of Strict support going forward. In short, we will support Strict no later than Office “15.” I’ll outline our general plans below, and ask you to stay tuned for more details as we get further into the Office 15 wave.
15 stands for the 15th generation of Office of course (announced for 2013) but Office 14 still has to get out. Expect me to continue to follow the debate and I am wondering if “strict” support would be ready prior to Doug Mahugh’s retirement.
… emphasized “and writing” there because we have already built read-only support for Strict into Office 2010, and Strict read-only support will also be available for Office 2007 SP2 through a downloadable filter.
If it is true what he wrote about legacy feature support you may find a contraction:
Strict is a subset of Transitional that does not include legacy features – this makes it theoretically easier for a new implementer to support (since it has a smaller technical footprint, so to speak), but also makes it less able to preserve the fidelity of existing documents.
Generally you would expect an application of Postel’s law:
Be conservative in what you do; be liberal in what you accept from others.
They do exactly the opposite. When will the generation of documents with legacy features terminate? Write support is essential for that.
Here is another post of orcmid:
What I am going to report is my observation of the simple state of affairs and how difficult it is to erase the past and jump to implementations that only produce what are called strict IS 29500 documents. Expecting that to have been achieved in two years is about as unobservant as belief that all Microsoft needed to have done was adopt ODF as its native format in the first place.
And adds ever more mess:
As part of the early maintenance work, some found it disturbing that there was no way to differentiate provisions of ECMA-376:2006 from IS 29500 transitional and of IS 29500 transitional from IS 29500 strict. The same namespaces were used for all of them. This issue was being addressed before the ink was dry on IS 29500:2008.
