Re: XS: Construction Rule Features

Subject: Re: XS: Construction Rule Features
From: James Clark <jjc@xxxxxxxxxx>
Date: Sat, 24 May 1997 11:11:02 +0700
At 15:30 23/05/97 -0400, Paul Prescod wrote:

>So I would prefer a more general way to have
>attributes in the "query" for an element construction rule. 
>An element construction rule with an attribute specified could be more
>specific than any without. Two rules with two different attributes
>specified would be of the same level and would be an error.

It would be nice if we could make the syntax for element construction rules
the same as that for patterns in match-element? and select-elements.  The
issue (as you realize) is how to deal with specificity.

In the following pairs, I think it's reasonably obvious that the second is
more specific:

(element FOO ...)
(element (FOO (A1 V1)) ...)

(element (FOO (A1 V1)) ...)
(element (FOO (A1 V1 A2 V2)) ...)

(element (FOO BAR) ...)
(element (FOO BAR (A1 V1)) ...)

But what about something like this:

(element (FOO (A1 V1) BAR) ...)
(element (FOO BAR (A1 V1)) ...)

I think the easiest solution would be to say that element construction rule
A is more specific that element construction rule B if

(a) A has more element type names than B, or
(b) A has the same number of element type names as B, but A has more
attribute names than B.

Then there's the issue of how to deal with rules with the same specificity.
There are several different possible approaches:

1. Say that the first (in the stylesheet) wins.  At the moment, within each
part of a style sheet, the meaning of the style sheet is not affected by the
order of the top level forms. I think this is a desirable property, and I
wouldn't like to change it.

2. Say that it's an error if there is in fact an element that matches two
rules with the same specificity.  I think that's a workable solution, though
it's rather a pain from an implementation poin of view.

3. Say that it's an error if  an element *could* match two rules with the
same specificity (even if there isn't any such element), ie it's an error to
have

(element (FOO (A1 V1)) ...)
(element (FOO (A2 V2)) ...)

even if there never is a FOO element with A1=V1 and A2=V2.

I think (2) is probably the way to go.

As a modification to any of 1, 2, 3, we could allow a priority to be
attached explicitly to an element construction rule, but that makes it hard
to allow multiple construct expressions within an element construction rule,
so I would rather not.

Is all this worth the complexity?

>Also, there is a common idiom in CSS stylesheets where one construction
>rule applies to many different GIs:
>
>H1, H2, H3, H4, H5{
>  font-family: Times New Roman,serif;
>  font-weight: 500;
>  font-style: normal;
>  font-size: 10pt;
>  color: #000000;
>}
>
>Could we do this too:
>
>(element H1 H2 H3 H4 H5 
>	(make paragraph 
>		(font-size: (calculate-size (GI)) ))

Not if we want to follow your earlier suggestion of allowing multiple
construct expressions.  Suppose that previously the stylesheet had

  (define H5 (empty-sosofo))

Is H5 an element type or a construct expression?

Something like this would work:

(element-group (H1 H2 H3 H4 H5)
  (make paragraph
     font-size: (calculate-size (gi))))

Is this worth the extra complexity?  I'm not sure.

James



 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist


Current Thread