[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?
> 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|