Re: Is it possible to test a macro argument?

Subject: Re: Is it possible to test a macro argument?
From: James Clark <jjc@xxxxxxxxxx>
Date: Fri, 01 Jan 1999 13:10:25 +0700
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. 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.

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

> 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.  If
experience suggests that the alternative is better, it is easily changed
(that's one reason we have drafts).

James


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread