[Top] [All Lists]

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

2019-10-07 03:39:27

On 3 Oct 2019, at 22:17, Imsieke, Gerrit, le-tex 
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> 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 haven’t 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: 

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 

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

XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
<Prev in Thread] Current Thread [Next in Thread>