- From: Michael Kay <mike@saxonica.com>
- Date: Tue, 27 Sep 2022 10:03:36 +0100
- To: Reece Dunn <msclrhd@googlemail.com>
- Cc: public-xslt-40@w3.org
> > The main thing that jumps out at me are how these new rules work when there are a mix of parameters. For example, MarkLogic has mixed functions that look like: > > declare function cts:correlation( > $value1 as cts:reference, > $value2 as cts:reference, > $options as xs:string* := (), > $query as cts:query? := (), > $forest-ids as xs:unsignedLong* := () > ) as xs:double? external; > > IIUC, I don't think this will work with the proposed rules -- specifically: > > * If there is a parameter declaration with plurality=multiple, then any remaining positional arguments are aggregated as a sequence and matched to that parameter declaration. > gives no way of specifying the parameters for $query and $forest-ids in the above function example. If $options, $query, and $forest-ids are all optional, then I don't think there's a problem. If you want to make $forest-ids multiple, then under my rules it needs to be declared BEFORE the two optional parameters, and the values of $query and $forest-ids can only be supplied by keyword. If you want to make $options multiple, then you need to supply $query and $forest-ids by keyword. > > The rationale for allowing QNames (EQNames in the grammar) is that the Param in a function declaration supports QNames, so if when calling a function the naming of a parameter is limited to NCNames, then you cannot use that with function parameters that are QNames. -- This leads to an asymmetry in the behaviour and results in an error that a user would expect to work. (Note: In my proposal in issue #54 I've made specifying a QName value for a map key an error.) I think the problem is that the standard options parameters in functions like serialize() and map:merge() (anything that uses the option parameter conventions) expect strings as the keys, not no-namespace-QNames. So when aggregating parameters into a map, unprefixed names have to be treated as strings rather than QNames. That's messy, but it's probably doable. Michael Kay
Received on Tuesday, 27 September 2022 09:04:17 UTC