- From: Christian Grün <cg@basex.org>
- Date: Fri, 17 May 2024 08:48:42 +0000
- To: Michael Kay <mike@saxonica.com>, "public-xslt-40@w3.org" <public-xslt-40@w3.org>
- Message-ID: <AS4PR09MB55495405FB17A4165F0DEB5CC7EE2@AS4PR09MB5549.eurprd09.prod.outlook.com>
Michael, thanks for sharing your thoughts: > but also offer parent() and ancestor() functions that take you back up the selection route. “root()” could be added as well; we would then have a function shortcut for retrieving the first and the last ancestor. A direkt link to the root node could also be helpful for update operations. > whether it should be built into underlying functions such as map:entries(). If functions are enhanced as well, I would favor an explicit “map:lookup($map, $key)” function, or a general “fn:lookup” function for maps and arrays. The existing 4.0 function “map:entries” currently returns a sequence of “{ $key: $value }” maps, and we have “map:entry($k, $v)”, which creates a single “{ $key: $value }” entry, and I think we shouldn’t change this symmetry. > I'm proposing to drop array-bound-checking when the lookup operator is applied to arrays. Absolutely in favor; I’ll never get used to the checks. I guess it would be too drastic to drop array checks in general? If we did, it would certainly be easier to align other map/arrays functionalities as well. > I think we probably do still need the label concept to support deep update, but we can hide it so labels are never directly exposed to users. I haven’t tried to implement the label concept yet (as indicated before, the comparable implicit scoring approach from XQuery Full Text didn’t make us happy, so I’m lingering it), but I could imagine that it would be possible to exclusively rely on the data structures that are returned by entry lookups, at least for snippets like this: update $authors { delete ?? entry::country, replace ? entry::Dazai ? entry::age with 38, insert { 'Akutagawa': { 'country': 'Japan' } } into . } > I'm currenly leaning towards the idea that the "selection" in an update e.g. S in (update $root replace S with V) should be required to select entries as delivered by ??entry::X, and to propagate the updates back up to the root (a) every entry needs to know what map/array it is part of, and (b) every map/array needs to know what entry it belongs to. Sounds good.
Received on Friday, 17 May 2024 08:48:51 UTC