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