Dear List,
I have some responses from Paul Grosso to questions about compound
properties.
Peter
Original Message
Subject: Re: Compound datatypes
Date: Wed, 03 Oct 2001 09:02:38 -0400
From: Paul Grosso [EMAIL PROTECTED]
To: Peter B. West [EMAIL PROTECTED], xsl-editors
[EMAIL PROTECTED]
Peter,
Thank you for your comments.
We are looking at the several messages you sent to xsl-editors,
but let me attempt a reply to this one that I hope will answer
several of your questions.
At 03:35 2001 09 21 -0400, Peter B. West wrote:
I find the definition of compound datatypes very confusing. From an
implementation point of view, I find myself treating the compound
types not as datatypes but as another form of shorthand, whose major
difference from the existing shorthand properties is in the handling
of inheritance.
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.
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
This question is more involved because of corresponding properties.
In an lr-tb environment, border-top-width
