Re: DR 17-0019 — SML: Order of Elements in schemeClr

[Francis Cave]

Hi Charlie

I think that the reason that EG_ColorTransform is defined as an 
<xsd:choice> is purely an artefact of the way that XML schemas express 
"any combination of". It looks odd, but trying to specify something 
similar using <xsd:sequence> would be much messier and would prevent you 
from expressing certain transformations in which the same transform is 
used more than once, e.g.

- change the saturation by a certain amount
- add some blue
- change the saturation again by a different amount.

This might be bizarre, but there may be use cases for such things, 
preserving a cumulative series of colour transformations made by the 
user. I don't think we can outlaw such things.

I haven't been able to test this yet, but my guess is that the order of 
transformation is significant if the transformations are 
inter-dependent, i.e. they both accept the same colour component, but 
insignificant if the transformations are orthogonal in colour component 
terms. Thus, to give a trivial example, increasing the blue and reducing 
the green could be done in either order and the effect would be the 
same. This might be worth testing.

So, I think we have to leave the schema as it is. However, we could say 
more in the prose about the whole issue, including possibly providing 
some more helpful examples - although this might prove difficult.

I'm tasked with coming up with some possible edits for review during the 
current WG 4 meeting, so I expect there'll be more to share with you 
before the end of the meeting.

Kind regards,

Francis


On 14/11/2017 15:28, Charlie Clark wrote:
> Am .11.2017, 13:43 Uhr, schrieb Francis Cave <francis at franciscave.com>:
>
>>
>> I have some sympathy with Charlie regarding this DR.
>
> Hi to you all in Geneva,
>
> sorry I couldn't answer this last week: I was fighting a cold.
>
> I don't really think that this is an XML issue. The only question here 
> would be why a choice and not a sequence was chosen for the group.
>
> The real problem is interoperability. The schema is:
>
> <xsd:group name="EG_ColorTransform">
>     <xsd:choice>
>         <xsd:element name="tint" type="CT_PositiveFixedPercentage" 
> minOccurs="1" maxOccurs="1"/>
>         <xsd:element name="shade" type="CT_PositiveFixedPercentage" 
> minOccurs="1" maxOccurs="1"/>
>         <xsd:element name="comp" type="CT_ComplementTransform" 
> minOccurs="1" maxOccurs="1"/>
>         <xsd:element name="inv" type="CT_InverseTransform" 
> minOccurs="1" maxOccurs="1"/>
>         <xsd:element name="gray" type="CT_GrayscaleTransform" 
> minOccurs="1" maxOccurs="1"/>
>         <xsd:element name="alpha" type="CT_PositiveFixedPercentage" 
> minOccurs="1" maxOccurs="1"/>
>         <xsd:element name="alphaOff" type="CT_FixedPercentage" 
> minOccurs="1" maxOccurs="1"/>
>         <xsd:element name="alphaMod" type="CT_PositivePercentage" 
> minOccurs="1" maxOccurs="1"/>
>         <xsd:element name="hue" type="CT_PositiveFixedAngle" 
> minOccurs="1" maxOccurs="1"/>
>         <xsd:element name="hueOff" type="CT_Angle" minOccurs="1" 
> maxOccurs="1"/>
>         <xsd:element name="hueMod" type="CT_PositivePercentage" 
> minOccurs="1" maxOccurs="1"/>
>         <xsd:element name="sat" type="CT_Percentage" minOccurs="1" 
> maxOccurs="1"/>
>         <xsd:element name="satOff" type="CT_Percentage" minOccurs="1" 
> maxOccurs="1"/>
>         <xsd:element name="satMod" type="CT_Percentage" minOccurs="1" 
> maxOccurs="1"/>
>         <xsd:element name="lum" type="CT_Percentage" minOccurs="1" 
> maxOccurs="1"/>
>         <xsd:element name="lumOff" type="CT_Percentage" minOccurs="1" 
> maxOccurs="1"/>
>         <xsd:element name="lumMod" type="CT_Percentage" minOccurs="1" 
> maxOccurs="1"/>
>         <xsd:element name="red" type="CT_Percentage" minOccurs="1" 
> maxOccurs="1"/>
>         <xsd:element name="redOff" type="CT_Percentage" minOccurs="1" 
> maxOccurs="1"/>
>         <xsd:element name="redMod" type="CT_Percentage" minOccurs="1" 
> maxOccurs="1"/>
>         <xsd:element name="green" type="CT_Percentage" minOccurs="1" 
> maxOccurs="1"/>
>         <xsd:element name="greenOff" type="CT_Percentage" 
> minOccurs="1" maxOccurs="1"/>
>         <xsd:element name="greenMod" type="CT_Percentage" 
> minOccurs="1" maxOccurs="1"/>
>         <xsd:element name="blue" type="CT_Percentage" minOccurs="1" 
> maxOccurs="1"/>
>         <xsd:element name="blueOff" type="CT_Percentage" minOccurs="1" 
> maxOccurs="1"/>
>         <xsd:element name="blueMod" type="CT_Percentage" minOccurs="1" 
> maxOccurs="1"/>
>         <xsd:element name="gamma" type="CT_GammaTransform" 
> minOccurs="1" maxOccurs="1"/>
>         <xsd:element name="invGamma" type="CT_InverseGammaTransform" 
> minOccurs="1" maxOccurs="1"/>
>     </xsd:choice>
> </xsd:group>
>
> But the implementers notes and the narrative specification and, 
> apparently, Excel uses alphabetical order:
>
> alpha (Alpha)
> alphaMod (Alpha Modulation)
> alphaOff (Alpha Offset)
> blue (Blue)
> blueMod (Blue Modification)
> blueOff (Blue Offset)
> comp (Complement)
> gamma (Gamma)
> gray (Gray)
> green (Green)
> greenMod (Green Modification)
> greenOff (Green Offset)
> hue (Hue)
> hueMod (Hue Modulate)
> hueOff (Hue Offset)
> inv (Inverse)
> invGamma (Inverse Gamma)
> lum (Luminance)
> lumMod (Luminance Modulation)
> lumOff (Luminance Offset)
> red (Red)
> redMod (Red Modulation)
> redOff (Red Offset)
> sat (Saturation)
> satMod (Saturation Modulation)
> satOff (Saturation Offset)
> shade (Shade)
> tint (Tint)
>
> This means that *Off elements need to follow their *Mod counterpart. I 
> worked this out debugging a chart and it was the only significant 
> element. The purpose of the specification is to try and make this kind 
> of reverse engineering unnecessary. I'm enclosing two files with 
> sample charts illustrating the difference. In chartlines_1.xlsx the 
> chartlines are light grey but in chartlines_2.xlsx they are black. The 
> order of the lumMod and lumOff elements is the only difference.
>
> So, my preferred solution would have a sequence instead of a choice in 
> the schema. I accept that there may be good reasons for not doing so. 
> If this is not possible then I would suggest reordering the elements 
> of the group so that the default order is the same as in the narrative 
> documentation. The least viable solution would be to include a note to 
> this effect in the narrative. It would, of course, be great to get 
> Microsoft's take on this.
>
> If, as Francis says, we can also include information about viable 
> combinations then I'm all for it because this particularly element 
> group is used in awful lot of places. I haven't come across the need 
> to deal with this yet but it could be very useful.
>
> Thank you all for your help.
>
> Charlie