Subject: Re: XS: Construction Rule Features From: Paul Prescod <papresco@xxxxxxxxxxxxxxxxxxxxxxxxx> Date: Sat, 24 May 1997 21:44:56 -0400 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: XS: Construction Rule Features, James Clark | Thread | Re: XS: Construction Rule Features, James Clark |
Re: XS: Add element-with-id or map-, Paul Prescod | Date | DSSSL Design Question, Paul Prescod |
Month |