Hi Evan,

So nice to see you again in xsl-list.


> You could make some analogies with OOP polymorphism, in that apply-templates
> is a polymorphic function. Modes could be compared with method names, and
> match patterns could be compared (loosely) with subtyping for dynamic
> function resolution. In fact, if you look at the XML source document as
> "code" rather than just "data", then you end up with a sort of twice-removed
> function resolution. A given element in the source may result in executing
> some code in some template rule(s) somewhere. I've found that this
> twice-removed nature allows me to express software intentions quite clearly
> in XML without being bothered at all by implementation details.

You didn't mention here XML (or any other) schema -- how does a schema
language fit in this picture?

It seems to me that we need a mechanism to express not only a given
data type as data, but also to describe (formally, not in plain
English) the set of all possible operations on that data type. I
couldn't find such a concept in XML Schema, or was I wrong?


> 
> I suspect that my next step will be to finally wrap my brain around your
> work on XSLT as a functional language. I seem to be heading in that
> direction.

Wonderful!


Cheers,

Dimitre.