Deep Update

I've been working hard on getting a revised proposal together on deep update (I have a deadline, it's my topic for an XML Prague paper) and I thought I would share how my ideas are developing. It actually affects three areas, which are slowly converging: deep lookup, pins and labels, and update itself.

I'm proposing to rely heavily on the "pairs" modifier for lookup, which I propose to rename "entry". Doing a lookup `$v??entry::X` retains a lot more structured information about what has been found, and this makes some of the information previously tucked away into labels unnecessary. I'm currently thinking that if you use entry::X then (without any reliance on pins and labels) you should get back entries that not only contain a key and value, but also offer parent() and ancestor() functions that take you back up the selection route. I think we can specify this without any data model modifications or any need to dive into implementation mechanisms. There's a question about whether this functionality should be particular to the lookup operator, or whether it should be built into underlying functions such as map:entries().

I'm proposing to drop array-bound-checking when the lookup operator is applied to arrays. When your search involves multiple arrays, you don't want failures because one of them happens to be too short. The spec becomes simpler if we can make the behaviour of maps and arrays as similar as possible.

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'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.

Michael Kay
Saxonica

Received on Thursday, 16 May 2024 19:39:20 UTC