[x3d-public] fwd: [ANN] Saxon 11.1 released for XSLT support; Michael Kay interview

Wed Feb 2 07:48:09 PST 2022

I pretty much agree, but I think we should have stuck with Lisp.   I
understand the desire to have closing tags and text nodes.

What I miss from our S-expression product:  object ids for small updates.

What I don’t miss from our s-expression product:  numerical ids and tags
made debugging difficult.

My boss suggested we use SGML.   We probably could have adapted our
product.   If SGML did small updates, it probably would have been
preferable.   We had the concept sending back only the parts that changed
on a form.

Here’s the real kicker:  why haven’t we moved past low level stuff?  Is it
that the XSLT GUI tools are not widely available and open source?

Does anyone else remember XslByDemo?

John

On Wed, Feb 2, 2022 at 5:34 AM Brutzman, Donald (Don) (CIV) <
brutzman at nps.edu> wrote:

> … plus some particularly interesting excerpts from interview by Roger
> Costello on xml-dev mailing list.  Warning message: brain teasers ahead,
> enjoy!  8)
>
>
>
>
>
> *From:* Roger L Costello costello at mitre.org
> *Sent:* Saturday, January 29, 2022 8:06 AM
> *To:* xml-dev at lists.xml.org
> *Subject:* [xml-dev] Interview of Michael Kay on YouTube
>
>
>
> Excellent interview. Filled with tips, wisdom, humbleness, and humor.
> https://www.youtube.com/watch?v=2Zt9oJtFKGw&t=6s
>
> A few excerpts from the interview:
>
> 1. The BBC’s coverage of the 2012 London Olympics used the free version of
> Saxon.
>
> 2.  What makes a good product? Users must be able to understand the error
> messages. People will tell you, one thing I like about Saxon is the error
> messages. To me, a bad error message is something that really needs to be
> fixed. Error messages are what users are dealing with every day. They are
> reading my error messages. If those glare out as being unhelpful, as being
> badly spelt, then that’s their experience with the product, so it’s
> important to get it right. I put a lot of effort into those sorts of little
> details. Getting good error messages it really quite an art. Do you phrase
> the error message in terms of the proper terminology of the spec, or do you
> use the terminology that the users are using (which might be quite wrong)?
> For example, what many users call a “tag” isn’t what the spec calls a tag.
> They’ll use “tag” to mean “element.” So which word am I going to use in an
> error message? It’s quite hard to get that sort of thing right. Getting a
> balance between a message that is technically correct and a message that
> users understand, sometimes requires a fair bit of thought. And then you’ve
> got to phrase the error message in terms of what the user was trying to do,
> not what was going on internally. That again gives you a significant
> challenge. So you have to think about those sorts of things.
>
> 3. My project over the last year has been translating the Java code of
> Saxon into a C# version of Saxon. To do that, I had to write a translator
> for Java to C#. How do you write such a translator? Java has a syntactic
> structure, you parse it so you’ve got a tree structured information
> structure and you’re converting that into another tree structured
> information structure from which you generate C#. How do you transform one
> tree to another?
>
> 4. The benefit of XSLT is not that it’s XML, the benefit is its paradigm:
> you’re doing a recursive descent, rule-based transformation. That’s what
> XSLT is, it’s a rule-based language.
>
> 5. If you read a textbook on writing compilers, it talks about compiling
> as a pipeline of tree-to-tree transformations. That is exactly the typical
> architecture of an XSLT transformation.
>
> 6. The resistance to XSLT is because for most people (particularly
> programmers), XSLT is so different from anything they’ve ever seen before.
> Using XSLT requires some rewiring of the brain. The enthusiasts of XSLT get
> over this initial learning curve and discover why this weirdness is
> actually a good thing.
>
> 7. I sometimes find new technologies quite hard to get familiar with and
> adopt. That’s because when I look at a new technology I want to have a deep
> conceptual understanding of it before using it. I know other people who are
> much better at picking up something new. They have a different learning
> style. They learn by example. They see something that works, they bend it
> and adapt it and make it fit without ever having a deep understanding. You
> can over-intellectualize things. I’m on that end of the spectrum.
>
> 8. A lot of people have tried to create a different syntax for XSLT. It’s
> not that difficult to do. I think what’s happened is that when people have
> done it, they’ve realized that they thought syntax was the problem, but it
> wasn’t. The problem is not the syntax. The problem is the concepts: What is
> a template rule? What does apply-templates actually mean? You *think*
> syntax is the difficulty, but it’s not. The difficulty is actually the
> semantics of the language. Improving the syntax doesn’t help. The other
> thing is that once you’ve gotten past the stage of the syntax looking
> weird, you actually realize that there are some benefits to having an
> XML-based syntax. The benefits of any big XSLT-based application that I’ve
> seen ends up exploiting the fact that XSLT is XML. You’re using the same
> conceptual tool set to manipulate your data and your source code. That’s
> something that comes from Lisp. XML and XSLT are a continuation of the Lisp
> concept of not separating data from programs.
>
>
>
>
>
> all the best, Don
>
> --
>
> Don Brutzman  Naval Postgraduate School, Code USW/Br
> brutzman at nps.edu
>
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA
> +1.831.656.2149
>
> X3D graphics, virtual worlds, Navy robotics https://
> faculty.nps.edu/brutzman
>
>
>
> *From:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> *Sent:* Wednesday, February 2, 2022 3:24 AM
> *To:* X3D Public Mailing List (x3d-public at web3d.org) <x3d-public at web3d.org
> >
> *Cc:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> *Subject:* RE: fwd: [ANN] Saxon 11.1 released for XSLT support; Michael
> Kay interview
>
>
>
> Here is a tremendous interview with Michael Kay regarding Saxon (which we
> use extensively) and also development of software projects along with
> standards.  Michael has led W3C XSLT working groups and language
> development for many years.  Both his software documentation and his books
> are amazingly thorough (produced using XML/XSLT).
>
>
>
> Many great insights, worth repeated viewing.
>
>
>
>
>
>    - Shift-M/51: Michael Kay about XSLT, XML, and software business -
>    YouTube
>    - https://www.youtube.com/watch?v=2Zt9oJtFKGw&t=6s
>
>
>
> Yegor Bugayenko / Егор Бугаенко
>
> 14.9K subscribers
>
>
>
> Michael Kay is the editor of the W3C XSLT 2.0 and 3.0 language
> specifications for performing XML transformations and the developer of the
> Saxon XSLT and XQuery processing software.
>
>
>
> 0:00 Introduction
>
> 0:40 Is XML old?
>
> 3:32 Story of XML
>
> 11:22 Versions of Saxon XSLT
>
> 14:28 Michael's activity on Stack Overflow
>
> 20:42 Understanding of XSLT
>
> 24:43 XSLT simplification
>
> 27:16 How The W3C (World Wide Web Consortium) works
>
> 42:26 Compiling XSLT to binary code
>
> 59:43 Michael's favorite language
>
>
>
> My blog: https://www.yegor256.com
>
> My books: https://www.yegor256.com/books.html
>
> My GitHub: https://github.com/yegor256 (don’t hesitate to follow in order
> to stay informed)
>
> My Telegram channel with recent news and updates:
> https://t.me/yegor256news (subscribe to not miss a thing)
>
> My Twitter with daily and weekly updates: https://twitter.com/yegor256
> (follow me!)
>
>
>
> #xslt #interview #xml #programming
>
>
>
>
>
> Transcript:
>
>    - https://www.yegor256.com/shift-m/2022/51.html
>
>
>
> all the best, Don
>
> --
>
> Don Brutzman  Naval Postgraduate School, Code USW/Br
> brutzman at nps.edu
>
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA
> +1.831.656.2149
>
> X3D graphics, virtual worlds, Navy robotics https://
> faculty.nps.edu/brutzman
>
>
>
> *From:* Brutzman, Donald (Don) (CIV)
> *Sent:* Wednesday, February 2, 2022 2:40 AM
> *To:* X3D Public Mailing List (x3d-public at web3d.org) <x3d-public at web3d.org
> >
> *Cc:* brutzman at nps.edu
> *Subject:* fwd: [ANN] Saxon 11.1 released for XSLT support (Java C# C++
> Python PHP JSON)
>
>
>
> http://lists.xml.org/archives/xml-dev/202202/msg00000.html
> <https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.xml.org%2Farchives%2Fxml-dev%2F202202%2Fmsg00000.html&data=04%7C01%7Cbrutzman%40nps.edu%7C2d37a0eb5f6b41f73cb608d9e63e7a78%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637793978311075842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=af%2Bor0qBSDC6G9fsNNN0X4zXkkt7425zEjn9u72nSAA%3D&reserved=0>
>
>
>
> [ANN] Saxon 11.1
>
>    - *From*: *Michael Kay mike at saxonica.com <mike at saxonica.com>*
>    - *To*: xml-dev xml-dev at lists.xml.org
>    - *Date*: Wed, 2 Feb 2022 09:52:17 +0000
>
> ------------------------------
>
> We are delighted to announce Saxon 11.1, a raft of new products covering three language platforms (SaxonJ, SaxonCS, and SaxonC), all built from the same source code. The software can be downloaded from the usual places (see www.saxonica.com <https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.saxonica.com%2F&data=04%7C01%7Cbrutzman%40nps.edu%7C2d37a0eb5f6b41f73cb608d9e63e7a78%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637793978311075842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=aCECPIwHucbClCh7NOapiGBWfFl%2FeTpIaLykT5dJ2HQ%3D&reserved=0>) though a few corners of the website have yet to be updated.
>
>
>
> For SaxonJ (Java), this is the first major release in nearly two years. There's a long list of detailed changes that you can find in the documentation, but the main highlights are:
>
>
>
> * New functions and syntax extensions, some of them experimental. Some are very simple, for example, "A otherwise B" selects A if it exists, otherwise it selects B. Some are more complex and powerful, such as the saxon:update and saxon:deep-update instructions in XSLT. Please try them out and give us feedback.
>
>
>
> * A new framework for resolving URIs that refer to external resources, integrating catalog-based resolution where appropriate.
>
>
>
> * Most callbacks are now provided via functional interfaces, allowing them to be easily written as lambda expressions.
>
>
>
> * Timezone handling has moved forward to the modern Java date/time libraries.
>
>
>
> * Numerous minor changes to make JSON processing easier
>
>
>
> Internally, there's a set of classes for handling Unicode strings. The main motivation for this was to allow common code across Java and C#, but it also improves speed and reduces memory requirements for many string handling operations. The effect is not uniform however; for very simple transformations of documents consisting exclusively of ASCII text, there is generally a memory saving but a small overhead in processing time.
>
>
>
> For SaxonCS (.NET 5 and 6 on Windows, Mac, and Linux), this is essentially a bug-fixing release for 11.0. The most important issues fixed relate to localisation (in particular, running on machines whose default Culture setting is not English). For a full list of fixed bugs, please go to https://saxonica.plan.io/projects/saxon/issues <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsaxonica.plan.io%2Fprojects%2Fsaxon%2Fissues&data=04%7C01%7Cbrutzman%40nps.edu%7C2d37a0eb5f6b41f73cb608d9e63e7a78%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637793978311075842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=W6M732kq%2BBTHO2gxlmJg5ZX9h8JlVYXK5V%2B31bO9Z50%3D&reserved=0> and filter the list of bugs for those labelled as "fixed in maintenance release 11.1". In addition to bug fixes, there are some functional changes:
>
>
>
>   * As with SaxonJ, there is a new framework for resolving URIs, based on the C# version of the catalog-based xml resolver. The use of the System.Xml.XmlResolver interface has been largely discontinued, except where needed for interoperation with the Microsoft parser, because of its inflexibility in handling different kinds of resources.
>
>
>
>   * A few new API methods are implemented to plug gaps, in response to user feedback
>
>
>
>   * XQuery Update is fully supported (in 11.0 the code was present but largely untested).
>
>
>
> SaxonCS on Mac is still awaiting notarization from Apple; until that's achieved there may be security warnings when you download it.
>
>
>
> For SaxonC (C++, Python, and PHP, on Windows, Mac, and Linux) this is the first release since 2019.
>
>
>
> * The Java code base has moved forward from 9.9 to 11.1, and the build process is now integrated with SaxonJ and SaxonCS so that bug fixes can be applied simultaneously to all three products.
>
>
>
> * There are improvements in multi-threading, when multiple transformations using the same stylesheet are executed in parallel in a web server
>
>
>
> * Memory management of XDM objects is improved
>
>
>
> * Localization (using ICU-J) is improved
>
>
>
> * Handling of Unicode strings in the various language APIs is improved, reducing the scope for encoding issues.
>
>
>
> * There are many API extensions and improvements for all three languages (C++, Python, and PHP)
>
>
>
> Michael Kay
>
> Saxonica
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220202/7ec40cef/attachment-0001.html>