DR 14-0006: four more

[Jim Thatcher]

I agree with Chris on this. The standard should specify the basic information critical to interoperability, leaving flexibility for the market to innovate. Chris's proposed note recommending "mutual agreement between implementers" provides a nice pathway toward future standardization of additional values that multiple implementers find useful.

Jim

-----Original Message-----
From: Chris Rae [mailto:Chris.Rae at microsoft.com] 
Sent: Tuesday, August 12, 2014 10:09 AM
To: MURATA Makoto; SC34
Subject: RE: DR 14-0006: four more

I really don't like the idea of adding tight restrictions to these, for the same reason that I don't like restricting the values in Charlie's original suggestion. These are all enumerated lists where the first n values are provided by the standard - we really should leave the rest of the values available for application-defined expansion if necessary. It seems nonsensical that an Office application which wants to use a paper type not listed in the original standard must store the value in an ignorable attribute (or similar) instead of just utilising an unused enum in that list.

That said, it doesn't say anywhere in the standard that this is what implementers ought to do (or whether they are even permitted to). So my preferred resolution to these four and Charlie's original suggestion would be to add some text like:

"To maximize interoperability, implementers should restrict the content of this attribute to enumerations present in the above list. Additional values may be used, but interoperability will only be possible via mutual agreement between implementers."

I'll be happy to write up these changes if we can agree upon them in principle.

Chris

-----Original Message-----
From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of MURATA Makoto
Sent: 18 July 2014 00:31
To: SC34
Subject: DR 14-0006: four more

Dear colleagues,

I checked number 33 as an example.   In some sublclauses.
this number appears as an enumerated value but there
are no tight restrictions in schemas.   Here goes.


18.8.30 numFmt
@numFmtId

  <xsd:simpleType name="ST_NumFmtId">
    <xsd:restriction base="xsd:unsignedInt"/>
  </xsd:simpleType>

18.8.7 cellStyle
@builtInId (see G.7)

<xsd:attribute name="builtinId" type="xsd:unsignedInt" use="optional"/>

18.3.1.63 pageSetup (Page Setup Settings) @paperSize <xsd:attribute name="paperSize" type="xsd:unsignedInt" use="optional"
default="1"/>

18.3.1.64 pageSetup (Chart Sheet Page Setup) @paperSize <xsd:attribute name="paperSize" type="xsd:unsignedInt" use="optional"
default="1"/>

Should we provide tight constraints as part of schemas for these four attributes?

Regards,
Makoto