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.
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--