- 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