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

Re: XSLT 4: map serialization

Subject: Re: XSLT 4: map serialization
From: "Graydon graydon@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 25 Nov 2020 13:24:23 -0000
Re:  XSLT 4: map serialization
On Wed, Nov 25, 2020 at 10:07:15AM -0000, Michael Kay mike@xxxxxxxxxxxx scripsit:
> I've recently proposed that we should have a library of XPath functions for constructing nodes: see https://www.saxonica.com/~mike/builder.html This was motivated by this kind of use case, and I'm now wondering whether such functions should go into the core (though there's an interesting question about how they should be named). It seems XForms has also extended the function library with node-building functions.

I think such functions should be core for general portability.

The immediate drawback to writing my own library of XPath functions is that it's mine; it's not portable at all. (And its quality is limited by my time and skill, rather than being distributed over a community.)  It increases the maintenance cost of any solution in which it is used, which is the wrong thing to do.  Node constructors in XPath are so immediately and obviously useful that I'd expect wide use, so the lowest maintenance approach is to make them core functions in presently hypothetical XPath 4.0.

> > Allowing XQuery anonymous functions would be a large change, but at least in the map serialization case[1] I have trouble thinking of a better option.  XQuery functions are at least already well-defined.
> 
> There are far too many things that can currently be done only using custom syntax rather than using functions. That's true across XPath, XSLT, and XQuery. Higher-order functions give us the opportunity to do many things such as grouping without custom syntax. In fact there are plenty of things that should have been functions in the first place: for example array{$x} is ridiculous, it could easily have been array($x). Providing new functionality by adding to the function library should definitely be the aim, because it's easier to implement and more versatile for users.

No argument from this corner.

> > [1] I cannot tell you how much I want to be able to pass parameters to a functioned returned from a map of function items and have that function return elements for applying-a-style purposes, e.g.
> > 
> > <xsl:sequence select="$stylesMap($styleTypeName)($stylePropertiesMap($styleName))" />
> > 
> Not sure what there is here that doesn't already work?

The node constructors in the anonymous functions referenced by $stylesMap.

The syntax works, but the XPath node constructors aren't there, so I
can't do "this element, like many other elements, produces fo:block; call the fo:block construction function from the map of construction functions and pass in the map of formatting options specific to this element while we're at it".


-- 
Graydon Saunders  | graydonish@xxxxxxxxx
^fs oferiode, pisses swa mfg.
-- Deor  ("That passed, so may this.")

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.