Re: XS: Construction Rule Features

[Paul Prescod <papresco@xxxxxxxxxxxxxxxxxxxxxxxxx>]

James Clark wrote:
> 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.

I agree.
 
> 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.

Would it make sense to restrict attributes to the last node? That would
meet the need I have noticed in stylesheets.

It seems arbitrary, but any rule we come up with is fairly arbitrary. I
am not 100% comfortable with counting attributes without reference to
their position. I can't quite think of any proposal that doesn't sound
arbitrary, though, so I won't oppose it.

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

Isn't this only a problem if the priority is an *expression*. What if it
were required to be a constant number:

(element foo 5 (make blah blah blah))

5 can only be a priority number because it certainly isn't an expression
that could return a sofofo. 
 
> Is all this worth the complexity?

You already have to handle consruction rules with the same specifity
whether or not you allow attributes to be attached to construction
rules, so yes, I would say allowing attributes makes sense. Attaching a
number? Maybe not. I haven't actually wanted that feature yet. If I did,
I would worry that my stylesheet was getting too complex and perhaps
hard to maintain.
 
> Not if we want to follow your earlier suggestion of allowing multiple
> construct expressions.  

Doh! Sure, throw my previous suggestions in my face!

> Suppose that previously the stylesheet had
> 
>   (define H5 (empty-sosofo))
> 
> Is H5 an element type or a construct expression?

Once again this could be solved if instead of H5 we said 'H5, since that
symbol is self-evaluating. But that would be a special rule since you do
not typically use symbols in construction rule "queries".
 
> 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.

I feel so, in a future full DSSSL at least. Grouping mechanisms help you
to organize your thoughts and shrink your stylesheets. OTOH, I would not
expect this idiom to be as common as it is in CSS, because in CSS
multiple rules work on the same element, so the rules for an element can
be spread out among many rules. If we moved to another (perhaps more
verbose) syntax, these problems could be a little easier to solve:

element H1 in H2{ ... }

element H1 or H2{ ... }

I find this more clear and readable than either CSS or DSSSL's.

 Paul Prescod


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