[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: What's the best feature in XSLT 3?

Subject: Re: What's the best feature in XSLT 3?
From: "Michael Kay mike@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 7 Oct 2019 08:39:21 -0000
Re:  What's the best feature in XSLT 3?
> On 3 Oct 2019, at 22:17, Imsieke, Gerrit, le-tex gerrit.imsieke@xxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> My unpopular take is that maps are not my favorite feature within XSLT 3.0.
>
> One reason is that I found it hard to process maps in an XSLT-idiomatic way.
But I guess I havenbt done enough research yet because, as I found out just
now, I can actually write template rules like this:
>
> <xsl:template match=".[. instance of map(xs:anyAtomicType, item()*)]">

I came to the same conclusion in my XML Prague 2016 paper on transforming
JSON: http://www.saxonica.com/papers/xmlprague-2016mhk.pdf

In that paper I put a lot of the blame on the fact that JSON tree structures
traditionally don't have parent pointers, which makes it impossible to match
objects by reference to their context in a containing document.

But I think that in that paper I missed a more fundamental point. XML elements
have names, and an element name in most cases corresponds to the name of a
class of real-world objects or entities: Employee, OrderLine, Paragraph,
Article. Most XSLT template rules match elements by name. But JSON objects
don't have [class] names, they only have properties, and while it is possible
to use one of the properties of an object to denote the class of real-world
thing that it represents, there is no universal convention for doing so. So a
JSON document might contain information about orders and order-lines without
ever identifying these by name; and it's this that makes it hard to write an
XSLT template rule for matching orders or order-lines. It means you have to
match orders and order-lines heuristically by recognising their properties, or
their context in a containing document, rather than explicitly by name.

At the root of this, of course, is "duck typing": if it walks like an employee
and quacks like an employee, then your code assumes that it IS an employee.

One solution to this might be to encourage JSON developers to use "class" as
the conventional property name for the class to which an object belongs, and
to provide custom syntax for matching JSON objects by class. One could also
perhaps define some mechanism for inferring the class of an object from its
context and/or properties.

>
> Constructing (nested, in particular) maps tends also to be more verbose than
just constructing an XML structure. (Imagine, an XSLT guy complaining about
verbosity!)

I'm not sure I agree with that. Certainly, there's the usual problem that you
have to choose between XSLT and XPath constructs, each of which has its own
advantages and disadvantages. But I don't think it's really worse than
constructing elements.

There's a gap, of course, in that we don't have XSLT 3.0 instructions for
constructing arrays. Saxon plugs that gap with extension insttructions.

Michael Kay
Saxonica

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.