Dear List,

I have some responses from Paul Grosso to questions about compound 


-------- 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 


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

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.
 >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
 >is equivalent to a specification of
 >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> 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:


7.7.9 says the initial value of 
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 
   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

Per the above discussion, border-before-width="10pt" equates to:


 >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
 >will have the effect of setting computed values of

Compound datatype "expansion" happens before refinement, and
property correspondence happens as part of refinement.  And
property correspondence maps individual properties into traits.

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:


(assuming lr-tb) ends up setting traits in a fashion equivalent to:



"Lord, to whom shall we go?"

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to