Re: DR 14-0010 — SML: Attribute textRotation

[MURATA Makoto]

John,

Thanks.  I prefer xs:enumeration rather than
the combination of minInclusive and maxInclusive.


  <xsd:simpleType name="ST_TextRotation">
    <xsd:union>
      <xsd:simpleType>
        <xsd:restriction base="xsd:nonNegativeInteger">
          <xsd:minInclusive value="180"/>
        </xsd:restriction>
      </xsd:simpleType>
      <xsd:simpleType>
        <xsd:restriction base="xsd:nonNegativeInteger">
          <xsd:enumeration value="255"/>
        </xsd:restriction>
      </xsd:simpleType>
    </xsd:union>
  </xsd:simpleType>

and

ST_TextRotation =
  xsd:nonNegativeInteger{ minInclusive ="180"}  |
  xsd:nonNegativeInteger "255"

Regards,
Makoto

2015-02-12 4:28 GMT+09:00 John Haug <johnhaug at exchange.microsoft.com>:

>  If we do add schema, since the allowed values (already in the standard)
> are 0-180 and we’re only adding mention of 255, should the schema instead
> add something like this?
>
>
>
> <xsd:simpleType name="ST_TextRotation">
>
>   <xsd:union>
>
>     <xsd:simpleType>
>
>       <xsd:restriction base="xsd:nonNegativeInteger">
>
>         <xsd:maxInclusive value="180"/>
>
>       </xsd:restriction>
>
>     </xsd:simpleType>
>
>     <xsd:simpleType>
>
>       <xsd:restriction base="xsd:Integer">
>
>         <xsd:minInclusive value="255"/>
>
>         <xsd:maxInclusive value="255"/>
>
>       </xsd:restriction>
>
>     </xsd:simpleType>
>
>   </xsd:union>
>
> <simpleType>
>
>
>
> There’s likely a better way to write this…  If we add 0-360 as valid
> values, the prose needs to change and it adds new behavior for
> implementations.  Not necessarily bad, but it’s new.  How do other
> implementations handle 181-360?
>
>
>
> John
>
>
>
> *From:* eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] *On Behalf Of *MURATA
> Makoto
> *Sent:* Saturday, February 7, 2015 2:56 AM
> *To:* e-SC34-WG4 at ecma-international.org
> *Subject:* Re: DR 14-0010 — SML: Attribute textRotation
>
>
>
> Re: Issue 1/2  Ideally, every condition in prose should be captured by
> schemas.
>
> Here is my prposal.
>
>
>
> Replace
>
>
>
>     <xsd:attribute name="textRotation" type="xsd:unsignedInt"
> use="optional"/>
>
>
>
> in sml.xsd by
>
>
>
>     <xsd:attribute name="textRotation" type="ST_TextRotation"
> use="optional"/>
>
>
>
> and add
>
>
>
>   <xsd:simpleType name="ST_TextRotation">
>
>     <xsd:restriction base="xsd:unsignedInt">
>
>       <xsd:minInclusive value="0"/>
>
>       <xsd:maxExclusive value="360"/>
>
>     </xsd:restriction>
>
>   <simpleType>
>
>
>
> Replace
>
>
>
>   attribute textRotation { xsd:unsignedInt }?,
>
>
>
> in sml.rnc by
>
>
>
>   attribute textRotation { sml_ST_TextRotation }?,
>
>
>
> and add
>
>
>
> sml_ST_TextRotation =
>
>   xsd:unsignedInt { minInclusive = "0" maxExclusive = "360" }
>
>
>
> Regards,
>
> Makoto
>
>
>
>
>
>
>
> 2015-01-14 9:26 GMT+09:00 Chris Rae <Chris.Rae at microsoft.com>:
>
> DR is here:
> https://onedrive.live.com/view.aspx/Public%20Documents/2014/DR-14-0010.docx?cid=C8BA0861DC5E4ADC
>
> I've done a bit of investigation into this DR and it seems to definitely
> represent an omission either from the standard or from Microsoft's
> implementer notes. The DR mentions several things:
>
> 1. the actual schema has unsignedInt while the description clearly imposes
> limits;
> 2. an unsignedInt is clearly not restrictive enough in this respect (0 < x
> 359 should be sufficient);
> 3. the value of 255 seems to be specifying different, undefined behaviour
> (ideally this should probably be controlled by a separate attribute). Excel
> at least seems to treat values > 180 as negative.
>
> Issue 1/2: I don't feel strongly on this, although we do have many others
> cases where ranges are specified in prose rather than schema. Rather than
> open that can of worms, I propose not adding this limit to schema.
>
> Issue 3: I've tested this in Microsoft Office, LibreOffice, Open Office
> and Google Docs. Google Docs appears not to support text rotation at all,
> but the other three applications do indeed all treat the value 255 as
> special, and meaning text written downwards. I therefore propose the
> attached changes to the standard to address this.
>
> On Excel's treatment of values >180, it does appear to be slightly odd but
> I don't think this is deliberate and there's no way to recreate it in the
> user interface. As the standard doesn't dictate what to do with invalid
> files, I don't think we need to document this case (and, if we do, I think
> it should be in Excel's implementer notes).
>
> Chris
>
>
>
>
>
> --
>
>
> Praying for the victims of the Japan Tohoku earthquake
>
> Makoto
>



-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20150212/4edc3cad/attachment-0001.html>