DR 13-0014 "PML: omissions and inconsistencies in the specification of attributes"

[MURATA Makoto]

Francis,

Thank you for reading [MSOI29500].pdf.

1.1.1                      rCtr (Rotation Center)

2017-11-21 9:55 GMT+09:00 Francis Cave <francis at franciscave.com>:

> Hi Aarti
>
>
>
> The minutes of the Geneva meeting include the following:
>
>
>
> *DR 13-0014 “PML: omissions and inconsistencies in the specification of
> attributes”*
>
>
>
> New questions for MS experts re animMotion:
>
>
>
> 1. Does the ptsTypes attribute always contain a list of ptsTypes whose
> length is determined by the number of segments in the path?
>
>
>
> 2. Can the ptsTypes attribute contain an empty list, “”?
>
>
>
> New question for MS experts re cmd:
>
>
>
> 3. Please confirm that if @cmd is omitted or has an empty string value,
> regardless of the value of @type, the element has no effect and is
> equivalent to the element being omitted, and that no other interpretation
> makes sense.
>
>
>
> Assigned to Aarti.
>
>
>
> I have now done what I should have done in Geneva, which is to read the
> implementer notes in [MSOI29500].pdf.
>
>
>
> This is what they have to say about @ptsTypes on element §19.5.4
> animMotion:
>
>
>
> d. *The standard states that the ptsTypes attribute specifies the types
> of points in the path attribute.*
>
>
>
> In Office, the ptsTypes attribute additionally describes what the motion
> path should look like around the current point. This attribute has no
> effect on the playing of the animation. It is only used when the motion
> path is edited in Office.
>
>
>
> Each character in this string sequentially maps to a point defined in the
> path string. If there are more entries than points, the extra entries are
> ignored. If there are fewer entries than points, the extra points are to be
> treated as follows: If the action *after *the point is a Line To, then
> the point is treated as an ‘F’ (corner line). Otherwise, the point will be
> treated as an ‘f’ (corner curve).
>
>
>
> I think we should therefore reconsider the questions to the PowerPoint
> team experts, since the final paragraph of the implementer note implies
> that the answer to Q1 is clearly “yes”, and the answer to Q2 is clearly
> “yes” as well.
>

My take is different.  I think that the answer to Q1 is "No", since extra
entries are ignored and missing entries are assumed to be 'f';.


>
>
> There are no implementer notes on @cmd on element §19.5.28 cmd, so Q3 is
> still worth asking.
>
>
>
> Regarding @ptsTypes on animMotion, I suggest that we replace Q1 and Q2
> with a new question: can the PowerPoint team see any reason for not
> tightening the schema so that the string value of @ptsTypes is constrained
> to match the following pattern: “[AFTSafts]*” ?
>

I suppose that any whitespace character is need as separators.   How about
this?

  <xsd:simpleType name="ST_PtsTypes">
    <xsd:list itemType="ST_PtsType"/>
  </xsd:simpleType>

  <xsd:simpleType name="ST_PtsType">
    <xsd:restriction base="xsd:string">
      <xsd:enumeration value="A"/>
      <xsd:enumeration value="F"/>
      <xsd:enumeration value="T"/>
      <xsd:enumeration value="S"/>
      <xsd:enumeration value="a"/>
      <xsd:enumeration value="f"/>
      <xsd:enumeration value="t"/>
      <xsd:enumeration value="s"/>
    </xsd:restriction>
  </xsd:simpleType>

sml_ST_PtsTypes = list { sml_ST_PtsType* }
sml_ST_PtsType =
  string "A"
  | string "F"
  | string "T"
  | string "S"
  | string "a"
  | string "f"
  | string "t"
  | string "s"


Regards,
Makoto

>
>
> Kind regards,
>
>
>
> Francis
>
>
>



-- 

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/20171213/399b0b9d/attachment.html>