DR-08-0012 Namespace Mapping Table v2

[MURATA Makoto (FAMILY Given)]

Folks,

WG4 has decided to change namespaces for "strict" in our FPDAM.
At this stage of the game, I welcome discussions for improving the
FPDAM for example by providing better justifications.  I do not
welcome discussions for reverting that decision.  Unfounded guess of
MB ballots is very inappropriate.  Use /dev/null rather than the WG4
mailing list.

There is certainly a concern about the future of the conformance class
"strict".  One extreme position is to throw it away.  Another extreme
position is to throw away the conformance class "transitional".  The
BRM clearly rejected these two positions.  I believe that WG4 should
maintain both classes and establish a long-term plan about the
relationship of the two.  Discusssion papers or presentations at the
Denmark meeting (and beyond) are very welcome.


Regards,

SC34/WG4 Convenor
MURATA Makoto (FAMILY Given)



> MURATA Makoto (FAMILY Given) wrote:
> > Rick,
> >
> > Yes, you are very late.  I am reluctant to revisit our decision 
> > to change the namespaces for "strict".  Revisiting it would be
> > disappointing to those who have spent a lot of time on it and
> > contributed to it significantly.
> >   
> Yes, and I apologize for raising the issue after it has been raised. I 
> am not calling for the
> issue to be re-opened now. But I hope WG4 will double-check it before 
> the draft.
> 
> 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, 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.
> 
> 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).   They will say:
> 
> * If a new language is needed, it should be ODF
> * This does not help interoperability, because it creates a third thing 
> people have to support
> * This goes against the thrust of what the BRM intended for Strict
> * This gives MS more wiggle room to delay and avoid supporting or 
> switching to Strict
> 
> Cheers
> Rick Jelliffe