On 3 Oct 2019, at 22:17, Imsieke, Gerrit, le-tex
gerrit(_dot_)imsieke(_at_)le-tex(_dot_)de
<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:
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
--~----------------------------------------------------------------
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
--~--