Re: Is it possible to test a macro argument?

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