Re: Macro Arguments

[David Rosenborg <David.Rosenborg@xxxxxxx>]

Paul Prescod wrote:
> 
> It would be nice if macro arguments were not restricted to being strings.
> I can imagine that I might have a special kind of table that I want to use
> in many different contexts, with many different element types. Then I
> might want the "sosofo" representing the table's rows to be the argument.


I concur. As a matter of fact XSL macros allow for a single argument
of that kind as the body of the invoke element is passed to the macro.
It would be nice if this was turned into a general mechanism.

One way of doing it:

In another XML-based (non-styling) language I'm working on, macros have
the following general layout:

<!ELEMENT macro (arg*, %any;*)>

<!ELEMENT invoke (arg*)>
<!ATTLIST invoke macro CDATA #REQUIRED>

<!ELEMENT arg ANY>
<!ATTLIST arg
  name    NMTOKEN #IMPLIED
  value   CDATA #IMPLIED
>

arg elements can either specify the value attribute which is
interpreted as an attribute template or contain sub elements/data:

<invoke macro="foo">

  <!-- String value -->

  <arg name="x" value="some text {attribute(bar)}"/>

  <!-- Result tree value -->

  <arg name="y">
    <foo>Some text</foo>
  </arg>

</invoke>

In contrast to XSL there is no body in the invoke element that
you can pass to the macro. You would have to use an argument for
that purpose.

Since this introduces a polymorphic behavior to arguments, that is,
they can be either strings or "sosofos", it might not fit well in
the XSL processing model. What happens if you specify a 
sosofo-argument in an attribute template in the macro body?
In my application this works by extracting the character data
of the sosofo and turing into a string. But then, that isn't XSL
and the polymorphism is built-in from the beginning.

Cheers,

</David>

__________________________________________________________
David.Rosenborg@xxxxxxx                   OM Technology AB


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