Re: Compound datatypes

Paul,

Thanks for your timely response.

Paul Grosso wrote:

...

> You are right that compound datatypes are not the same
> thing as shorthands.
>
>
>>"Shorthand properties do not inherit from the shorthand on the
>>parent. Instead the individual properties that the shorthand expands
>>into may inherit." 5.2
>>
>>On the other hand, 5.11 has: "Compound values of properties are
>>inherited as a unit and not as individual components."
>>
>>In other respects, compounds parallel shorthands.  "The compound
>>datatypes, such as space, are represented in the result tree as
>>multiple attributes."  In other words, the compounds expand into
>>individual properties, like the shorthands.
>>
>>It seems to me that when talking about a datatype, one expects to be
>>specifying the kind of data that may be assigned to particular
>>attributes/properties.
>>
>
> This is not how we did it in the XSL spec.  Instead, our datatypes
> are for the refined values, not the specified values.  Hence, things
> like "inherit" and percentages are not considered part of the datatype.
>
> We will look into making this clearer in section 5.11.
>


However, section 5.11 contains

<percentage>

     A signed real percentage which consists of an optional '+' or '-'
character followed by a sequence of digits followed by an optional '.'
character and sequence of digits followed by '%'. A property may define
additional constraints on the value.

Further, most of the datatypes are defined syntactically, as above, presumably so that the specified value in the FO element attribute can be parsed.  Am I correct in assuming that there are no constraints on the way implementations choose to represent refined values?


>>Compounds are not datatypes in that sense.
>>They partially specify the name of the attribute, and specify the type
>>of data which may be assigned to those attributes.  In my limited
>>experience, I have never encountered such a datatype before, and I was
>>very confused by them.
>>
>><length-conditional>
>>
>>I have a few specific questions about this compound.  It occurs in
>>association with the relative edge width specifications for border and
>>padding, and in a few other places.
>>
>>When the compounds are discussed, the examples of <space> and <keep>
>>are used.  In those cases, a single assignment to the compound implies
>>a series of assignments to each of the component properties.  So
>>
>>space-before="4.0pt"
>>
>>is equivalent to a specification of
>>
>>space-before.minimum="4.0pt"
>>space-before.optimum="4.0pt"
>>space-before.maximum="4.0pt"
>>space-before.precedence="0"
>>space-before.conditionality="discard"
>>
>>Similarly with <keep>.
>>
>
> Correct (precedence and conditionality take their initial value).
>
>
>>What about border-before-width?  The legal values for
>>border-before-width are specified as
>><border-width>|<length-conditional>|inherit
>>
>><border-width> is defined in 7.7.21 "border-top-width" to have the
>>possible values "thin", "medium", "thick" or <length>.
>>
>
> Specified values such as "thin", "medium", "thick" are refined into
> a length.
>
>
>><length-conditional>, as is explained in 7.7.9 "border-before-width",
>>has .length and .conditionality components, with an initial value for
>>.conditionality of "discard".  However, according to Appendix C, the
>>initial value for border-before-width is "medium".  There is no
>>mention of .conditionality.
>>
>
> The assignment (or initial value) of border-before-width="medium" equates to:
>
> border-before-width.minimum="medium"
> border-before-width.optimum="medium"
> border-before-width.maximum="medium"
> border-before-width.conditionality="discard"
>
> 7.7.9 says the initial value of border-before-width.conditionality="discard".
> Note that 5.11 says:
>
>   A short form of compound value specification may be used, in cases where
>   the datatype has some <length> components and for the <keep> datatype.
>   In the first case the specification consists of giving a <length> value
>   to an attribute with a name matching a property name. Such a specification
>   gives that value to each of the <length> components and the initial value
>   to all the non-<length> components.
>
> and that applies to <length-conditional> and hence border-before-width.
>
>
>>Given these definitions, what am I to make of an assignment like
>>border-before-width="10pt"?  Is this a <border-width> or a
>><length-conditional>?  To what do I assign the "10pt"?
>>border-before-width or border-before-width.length or both?  Does any
>>such assignment to border-before-width imply an assignment to
>>border-before-width.length and border-before-width.conditionality as
>>well?
>>
>
> Per the above discussion, border-before-width="10pt" equates to:
>
> border-before-width.minimum="10pt"
> border-before-width.optimum="10pt"
> border-before-width.maximum="10pt"
> border-before-width.conditionality="discard"
>

There are two points on which I am confused about this <length-conditional> for the relative border properties.  The first is that the .conditionality initial value is not given in the  'Initial' field of either 7.7.9 or the summary, unlike the space or keep property definitions, where the initial values for each of the components is given in this field.  The second is that this ambiguity reinforces the ambiguity in the definition of 7.7.9, where the allowable values include a double specification of length - once as part of a <border-width> (itself defined in 7.7.21) and once as part of the <length-conditional>.

On the face of it, this ambiguity derives from the attempt to express the property as a superset of the nearest corresponding CSS2 property.

Your comments illustrate that, in fact, <border-width> is not an alternative allowable value; that any assignment is in fact to a <length-conditional>.  In other properties, this might be expressed as

thin | medium | thick | <length-conditional> | inherit

which would remove one source of ambiguity.

>>This question is more involved because of corresponding properties.
>>In an lr-tb environment, border-top-width is a corresponding
>>property.  But <length-conditional> is not defined for
>>border-top-width.  Does the fact that computed values percolate to
>>corresponding properties imply that
>>
>>border-top-width="10pt"
>>
>>will have the effect of setting computed values of
>>
>>border-top-width="10pt"
>>border-before-width="10pt"
>>border-before-width.length="10pt"
>>border-before-width.conditionality="discard"
>>
>
> Compound datatype "expansion" happens before refinement, and
> property correspondence happens as part of refinement.  And
> property correspondence maps individual properties into traits.

Doesn't the above imply that the components of a compound are assigned to before refinement?

> The intent in the case of compound datatypes is that each
> individual component is mapped into a trait during the
> refinement process.
>
> We will try make this more explicit somewhere (either in 5.3
> or 5.11, I would think, but the editors will decide).
>
> Explicit assignment to a relative property isn't overridden
> by the mapping of absolute to relative and components are
> handled individually.  Therefore, for example:
>
>   <fo:wrapper
>         border-top-width="10pt"
>         border-top-width.minimum="5pt"
>         border-before-width.optimum="20pt">
>
> (assuming lr-tb) ends up setting traits in a fashion equivalent to:
>
>         border-before-width.minimum="5pt"
>         border-before-width.optimum="10pt"
>         border-before-width.maximum="20pt"
>         border-before-width.conditionality="discard"
>
> paul

I'm sorry if this is repetetive, but I still see a problem here.

Peter

-- 
Peter B. West  pbwest@powerup.com.au  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"

Received on Friday, 5 October 2001 11:11:13 UTC