Subject: Re: Is it possible to test a macro argument? From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx> Date: Fri, 1 Jan 1999 15:23:08 +0200 |
James Clark <jjc@xxxxxxxxxx> wrote: >Oren Ben-Kiki wrote: > >> ...testing macro arguments is really something >> which should be possible. Constants, too. > >I agree. The way the current WD handles string expressions isn't very >satisfactory. One solution is say that arg(foo) returns a free-standing >text node rather than a string, and so is allowed in the same places as >pi() or text(). The syntax is broken too: in the WD we changed from >attribute(foo) and pi(foo), to @foo and pi("foo"); we need a similar >change to arg() and constant(), ie it needs to be either arg("foo") or >something like $foo. That would be nice, but you'd need something different for 'arg' and 'constant' otherwise name collisions would become an issue. How about '$' for 'arg' and '$$' for 'constant'? >Also to make >test="arg(foo)='bar'" > >legal we would need to say that the value of test is a BooleanExpr (what >goes inside square brackets) not a SelectExpr. In which case the 'expr' name would be more fitting, but: >> I also find it strange that 'expr' was changed to 'select'. It would have >> been nice if each 'select' was a select pattern, each 'match' was a match >> pattern, each 'test' was a test expression, and each 'expr' was a string >> expression... I suppose there was a good reason for this rename - could >> someone post it? > >In the majority of cases, when the value of the select attribute of >value-of is a SelectPattern, it is confusing to have to use a different >attribute name from all the other cases where the value of an attribute >is a select pattern. If things change were to change in in the way I >outline above, then it would always be a select pattern. That would be best, since it would allow using the argument value in any select experssion within the macro, and constant values everywhere. I hope that renaming the attribute to 'select' hints that this is the prefered direction :-) >> Another question: for each template processing mode, there's an implicit: >> >> <xsl:template match="*|/" mode="the-mode"> >> <xsl:apply-templates/> >> </xsl:template> >> >> Shouldn't it be: >> >> <xsl:template match="*|/" mode="the-mode"> >> <xsl:apply-templates mode="the-mode"/> >> </xsl:template> >> >> Instead? It easy enough to work around, but strange. Is this intentional? > >The WG considered this alternative. My memory of the discussion is that >it was felt to be simpler to have one built-in rule that always applies >when there's no matching template rules, than having a separate, >different built-in template rule one for each processing mode. I see; you have a single built-in magical rule which say: <xsl:template match="*|/" mode="<anything>"> <xsl:apply-templates> </xsl:template> Even though there's no way to say mode="<anything>". But if the rule is already magical, you might as well say that it is: <xsl:template match="*|/" mode="<anything>"> <xsl:apply-templates mode="<current-mode>"> </xsl:template> Even though there's no way to say mode="<current-mode">. >If >experience suggests that the alternative is better, it is easily changed >(that's one reason we have drafts). I think the important point is that most people would _expect_ the second rule, regardless of whether it fits their application. I know I did :-) I've also been using modes quite a lot lately, and I haven't found any use for the current default rule, while I found lots of uses for the second one - but this might just be my particular application. Share & Enjoy, Oren Ben-Kiki XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Is it possible to test a macro , James Clark | Thread | Implementing Equality Expressions.., Tyler Baker |
Re: Is it possible to test a macro , James Clark | Date | Implementing Equality Expressions.., Tyler Baker |
Month |