DR-08-0012 Namespace Mapping Table v2

[Alex Brown]

Dear Rick, all,

> However, I think it is important for WG4 to be very explicit about its
> goals: if we are creating an incompatible language with an
incompatible
> namespace,

It was the Fast Track process which created these incompatibilities,
both at the macro level (e.g. VML, compatibility settings) and at the
micro level (e.g. dates, measurement representation).

What WG4 is doing in this amendment is merely explicitly labelling what
*is* incompatible, as just that.

Besides, for people working with IS29500 at the XML level, I'm not so
sure, these days, that a different Namespace is quite such an obstacle:
DSRL adapters and XProc steps can make short work of such differences. 

> we need to have  1) good reasons why it fits in the scope of IS29500
> and 2) that MS is completely onside, to prevent us wasting our time.

The scope faces two ways, aiming at the "pre-existing corpus" and at
"facilitat[ing] extensibility and interoperability". It is an inherent
property of an IS that it is extended in response to demands from the
NBs -- that is why revision is an integral part of the JTC 1 maintenance
process.

I have always assumed that T is a dead-end format, aimed at the
"pre-existing corpus" and that S would be the target of revision. That
was the intent expressed in the original Canadian resolution (which text
unfortunately never found its way into the published IS, something DK
has registered as a defect). The Canadian text stated:

----begin
"The intent of this Annex is to enable a transitional period during
which existing binary documents being migrated to DIS 29500 can make use
of legacy features to preserve their fidelity, while noting that new
documents should not use them. [...]
This annex is normative for the current edition of the Standard, but not
guaranteed to be part of the Standard in future revisions. The intent is
to enable the future DIS 29500 maintenance group to choose, at a later
date, to remove this set of features from a revised version of DIS
29500."
----end
 
> I think there is little chance that a strict version of Open XML in a
> new namespace would be accepted by NBs (those not involved in WG4).

I'm not sure we should be placing too much weight on second guesses
about NB voting intentions in our work, but FWIW my sense is quite
different ...
 
> * If a new language is needed, it should be ODF

I don't think NBs will be happy with putting all their money on one
horse. Also, NBs will want to see any new features in MS Office be in
harmony with the IS.

> * This does not help interoperability, because it creates a third
thing
> people have to support

But S *is* a third thing. Interop will always have to be between
different versions of things, and note that ODF 1.2 is planned to be the
end of the line for that compatibility family, before "ODF-Next"
emerges.

> * This goes against the thrust of what the BRM intended for Strict

As above, I believe this actually mirrors NB intentions better.

> * This gives MS more wiggle room to delay and avoid supporting or
> switching to Strict

I do not believe NBs have a problem with MS sticking to T (so long as it
accurately reflects the "pre-existing corpus"). I think what NBs had a
problem with was publishing T as an IS, because of its design quirks --
and S was, to some degree, the NBs expressing this by expressing what
they thought the format *should have* been (rather than what it was).

- Alex.


--
Alex Brown
Convenor, ISO/IEC JTC 1 SC 34 WG 1
Editor, ISO/IEC 19757-5 (Extensible Datatypes)