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

[Francis Cave]

Hi Charlie

Aha! I now understand why we are discussing this at cross-purposes!

Consider the element schemeClr, which is the subject of your DRs.

The element schemeClr is defined within the element group 
EG_ColorChoice, in line 673 of Annex A.4.1 on page 3999 of 29500-1:2016. 
This element group is itself a choice group and, to my mind, the use of 
minOccurs and maxOccurs in this group is correct but misleading. The 
whole point is that each time the choice is made, one and only one 
element may be chosen, but if the choice is itself repeatable any number 
of times, any number of elements within the group may occur in any 
order. That is true of EG_ColorChoice (see, for example, CT_CustomColor) 
and also for EG_ColorTransform. This level of indirection is unhelpful 
to the casual reader, but avoids unnecessary repetition in the schema, 
and therefore makes it easier to maintain the schema (once you know how 
it works!).

Let me demonstrate this for the element schemeClr

Line 673 on page 3999 states:

     ...
     <xsd:element name="schemeClr" type="CT_SchemeColor" minOccurs="1" 
maxOccurs="1"/>
     ...

The complex type CT_SchemeClr is defined in lines 391 to 396 of the same 
clause on page 3993:

<xsd:complexType name="CT_SchemeColor">
     <xsd:sequence>
         <xsd:group ref="EG_ColorTransform" minOccurs="0" 
maxOccurs="unbounded"/>
     </xsd:sequence>
     <xsd:attribute name="val" type="ST_SchemeColorVal" use="required"/>
</xsd:complexType>

The element group EG_ColorTransform is specified in lines 275 to 306 of 
the same clause on pages 3991-2:

<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="invGamma" type="CT_InverseGammaTransform" 
minOccurs="1" maxOccurs="1"/>
     </xsd:choice>
</xsd:group>

The part highlighted in red makes it clear that the choice of a single 
element from EG_ColorTransform can be made any number of times.

We can produce a single in-line definition of the element schemeClr that 
eliminates all this indirection, to see better what is going on:

     ...
     <xsd:element name="schemeClr" minOccurs="1" maxOccurs="1">
         <xsd:complexType>
             <xsd:sequence>
                 <xsd:choice minOccurs="0" maxOccurs="unbounded">
<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="invGamma" type="CT_InverseGammaTransform" 
minOccurs="1" maxOccurs="1"/>
                 </xsd:choice>
             </xsd:sequence>
             <xsd:attribute name="val" type="ST_SchemeColorVal" 
use="required"/>
         </xsd:complexContent>
     </xsd:element
     ...

I hope you will agree that the minOccurs='"1" maxOccurs="1" applies to 
schemeClr and not to the elements in EG_ColorTransform. In which case 
the choice of color transform elements can indeed be made repeatedly, 
allowing any combination, including repetitions of the same transform 
element.

Kind regards,

Francis



On 14/11/2017 17:59, Charlie Clark wrote:
> Am .11.2017, 18:16 Uhr, schrieb MURATA Makoto <eb2m-mrt at asahi-net.or.jp>:
>
>> I still do not understand your remarks on schemas.  Do you
>> think that
>>   - a schema having (a|b)* , and
>>  - another schema having  (a?,b?)*
>> imply different semantics of documents?
>> To me, they are identical.
>
> I must be explaining myself poorly. My apologies. Elements in the 
> EG_ColorTransform group can must occur once and once only. So neither 
> (a|b)* nor (a?,b?)* is relevant, because they can produce arbitrary 
> combinations such as ababbba.
>
> What is relevant is the order (lumMod, lumOff) and not (lumOff, 
> lumMod). Or am I misinterpreting the group?
>
> Charlie


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20171114/89526979/attachment.html>