Re: Fwd: Pattern matching error in xsl:key

Chapman Flack <chap-JULfBfA8satPFr4CO1/[email protected]> Sun, 6 Sep 2020 14:45:22 -0400
Newsgroups gmane.text.xml.saxon.help,gmane.text.xml.xsl.general.mulberrytech
Message-ID <[email protected]>
On 09/06/20 14:09, Ihe Onwuka wrote:

> because in other languages those concepts  are usually syntactically
> distinctive and said syntactic distinctiveness is a clear  indication that
> distinctive behavior shouldn't be  unexpected.
> OTOH if you design systems where you provide smartass explanations for
> things that look the same behaving differently your users will just want to
> slap you.

I didn't design the system, I'm just a satisfied customer. Dr. Kay kind of
did design it, but I haven't wanted to slap him yet.

It does seem that one of the distinctive things about XSLT is that it is
itself written in the same concrete syntax as the data you process with it.
So you're naturally going to encounter cases where you have XML attributes
that represent data and other XML attributes that represent code, and you
have to keep straight which are which.

It's kind of an exclusive subset of languages that have that property
(Lisp also comes to mind). Sure, you can write Java programs that parse
and act on Java programs, or you could devise some way of representing
data in the form of Java programs filled with constants, but that's not
standard operating procedure the way it is for Lisp, or XML and XSLT.

Maybe you would find XML Query more to your liking? There's a large overlap
with XSLT in the stuff you can do, it has the same naturalness for operating
on XML data, the same ability to contain XML literals easily in code, but
it has its own language syntax rather than being folded back in and written
as XML, which is the aspect of XSLT that is leading to these surprises.

Regards,
-Chap