DR 14-0006: four more

[MURATA Makoto]

Chris,

Thank you for writing up the proposed solution.  When some
implementation receives an unexpected enumerated value,
what should it do?

Regards,
Makoto


2014-08-15 2:06 GMT+09:00 Chris Rae <Chris.Rae at microsoft.com>:
> I've written up the changes I suggested, in the attached file. Rex - I think we're agreed that we need to add the new cases that Murata-san found to the original DR - I've also written up my suggested changes to the DR.
>
> Chris
>
> -----Original Message-----
> From: Arms, Caroline [mailto:caar at loc.gov]
> Sent: 12 August 2014 12:21
> To: Jim Thatcher; Chris Rae; MURATA Makoto; SC34
> Subject: RE: DR 14-0006: four more
>
> I also agree.  Caroline
>
> -----Original Message-----
> From: Jim Thatcher [mailto:Jim.Thatcher at microsoft.com]
> Sent: Tuesday, August 12, 2014 2:03 PM
> To: Chris Rae; MURATA Makoto; SC34
> Subject: RE: DR 14-0006: four more
>
> 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



-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto