Input from Switzerland (CH) re WG4's processing of CH's DRs 08-0012, 08-0013, and 08-0014

[Rex Jaeschke]

-----Original Message-----
From: nolockin at gmail.com [mailto:nolockin at gmail.com] On Behalf Of Norbert
Bollow
Sent: Friday, June 12, 2009 9:14 AM
To: rex at RexJaeschke.com
Cc: Hans-Rudolf Thomann
Subject: Re: Defect Report

> "Of the Swiss comments, the Namespace one is probably THE big topic WG 4
is
> trying to address. It's a big change, WG 4 does appreciate the Swiss
> comment, and I've summarized what the WG 4 discussion has been. We'd want
to
> make sure Switzerland is comfortable with the resolved solutions to the
DR's
> Switzerland has also sent in. If there are issues, it'd be great to get
the
> concerns out and into WG 4 as soon as possible; definitely before WG 4
> completes the Copenhagen meetings Jun 22-24."

Dear Mr Jeschke,
  since the below-referenced DRs had been suggested by me, the convener
of our mirror subcommittee, Mr Thomann, has suggested to me that I could
directly email you my thoughts on remaining concerns.  I would appreciate
if you could forward these comments to WG4 for consideration.

Best regards
Norbert Bollow

--start---------------------------------------------------------------------
----------------------------------
DR 08-0012 - Schemas: Supposedly incorrect schema namespace names

1) Comments on the Editor's response:

The Editor has raised the following questions:

* Should such a change be made to all schemas in IS 29500, or only to
  those that have changed since the 2006 version?

* Is this correcting a defect or is it a change in functionality? That
  is, does any resulting change belong in a COR or in an amendment/revision?

On the first question:  I propose that the change be applied to all
schemas, including those which have not changed.  The justification for
this is that the schema version can communicate information not just about
the schema but about the standard as a whole.  Not all technically
significant changes of the format are reflected by schema changes.

On the second question:  It is a severe defect that it cannot in all cases
automatically be determined from OOXML files which version of the
specification they aim to conform to.  Furthermore, it is a severe defect
also because it breaks general software for validating XML against schemas,
because such software must rely on the assumption that the schema namespace,
together with the version attribute if one is present, uniquely identifies
the schema to validate against.


2) Comments on the WG's deliberations:

The problems can be resolved by means of a version attribute, but then
that version attribute needs to be a required attribute.  Otherwise it
does not solve the problems.

Regarding the objective "do no evil to the 29500 ecosystem", it should
be kept in mind that failing to introduce a reliable (in the sense of
not relying entirely on an optional element or attribute) way of
distinguishing IS 29500 documents from ECMA-376:2006 documents would
very likely have the effect of the market ignoring the contents of
IS 29500 in so far as they differ from what is specified in ECMA-376:2006.
The decision of allowing that to happen in a way which would at the same
time allow to pay mere lip-service to having an ISO/IEC standard would be
seen by critics as a deliberate undermining of the ISO/IEC standard.

Furthermore, in addition to the various aspects which are mentioned in
the "Defect Report Log" document, the issue of /risk in making changes
to implementation software/ deserves to be considered.  The situation
is that a new version of the standard results in the need to adapt the
software to make it correctly handle also input files which differ from
what was originally anticipated.  If there is a reliable way for
distinguishing the new kind of input files (i.e. files which may contain
the changed features) from the old kind of files, then an input filter
can be created for handling the new kind of input files without risk of
thereby breaking the existing functionality for correctly processing the
old kind of input files.  (This can be done by copying and modifying
source code from the existing input filter implementation.  If it is easy
to reliably distinguish the types of input file types, that makes it easy
to ensure that for the old kind of input files, the execution path will
not touch the modified input filter code.)  In particular, as soon as the
versioning problem is solved, it will be reasonably easy and risk-free
for Microsoft to add support for IS 29500 to "Office 2007" by means of
the next Service Pack.


DR 08-0013 - Shared MLs, Shared Simple Types: ST_String allowed
             characters and max length

The Editor's response correctly demonstrates that ST_String itself
should not have restrictions on allowed characters and maximum
length, while clarifying that instances of ST_String do not in
general permit this full generality.  The textual changes which
have been adopted in response to DR 08-0014 implement this.  This
however does not solve the practical problem that the standard
fails to specify anything with regard to allowed characters and
max length for the various uses of ST_String.  If for a given use
of ST_String, there are no restrictions on allowed characters and
max length, the standard should be unambiguous that that is the
case.  Therefore, all uses of ST_String should be systematically
reviewed and for each case it should be specified whether or not
there are restrictions on allowed characters and max length, and
liekwise with regard to other restrictions on the set of allowed
values.


DR 08-0014 - Shared MLs, Shared Simple Types: ST_String example
             description error

The WG's changes are a clear improvement, and they resolve the
issue that was raised in DR 08-0014.
--end-----------------------------------------------------------------------
--------------------------------