Expression for exploding "complex atomics" to maps

[ghislainfourny]

This is a counterproposal to the extension of the ? syntax to "complex atomics" such as dates.

The idea is that

Expr :fireworks:

explodes an atomic (like date, etc...) returned by Expr into a map (with fields year, month, etc).

(the choice of :fireworks: is arbitrary and a placeholder for any other reasonable choice of syntax)

It can also work on a sequence of atomics, returning a sequence of maps.

Then one can write

(current-date():fireworks: )?year

where the semantics of ? is completely unchanged.

Parentheses are here for clarity on precedence, but may or may not be needed depending on the relative precedence of :fireworks: and ?.

This way, :fireworks: could be combined and used with all other functionality applying to maps (functions, obtaining the keys, the values, etc), providing a more general functionality than only for ?-based lookup.

As raised in Slack, it would be clear to anybody seeing :fireworks: and getting an error with an XQuery 3.1 query that this is something new, rather than an existing ? with modified semantics

[ChristianGruen]

Hi Ghislain, a rather explosive proposal ;) So we could decide between 💥 and 🎆…

One (pretty boring) alternative would be a fn:to-map function, which binds the actual value to a value key and provide additional mappings depending on the type:

to-map(current-date())?year

[michaelhkay]

Yes, I did consider that approach. The downside is that it needs another magic symbol. An alternative would be a function

map:from(current-date())?year

but it doesn't read so nicely.

Michael Kay Saxonica

On 18 Dec 2020, at 16:02, Ghislain Fourny notifications@github.com wrote:

This is a counterproposal to the extension of the ? syntax to "complex atomics" such as dates.

The idea is that Expr 🎆 explodes an atomic (like date, etc...) returned by Expr into a map (with fields year, month, etc).

(the choice of 🎆 is arbitrary and a placeholder for any other reasonable choice of syntax)

It can also work on a sequence of atomics, returning a sequence of maps.

Then one can write (current-date()🎆)?year where the semantics of ? is completely unchanged.

Parentheses are here for clarity on precedence, but may or may not be needed depending on the relative precedence of 🎆 and ?.

This way, 🎆 could be combined and used with all other functionality applying to maps (functions, obtaining the keys, the values, etc), providing a more general functionality than only for ?-based lookup.

As raised in Slack, it would be clear to anybody seeing 🎆 and getting an error with an XQuery 3.1 that this is something new, rather than an existing ? with modified semantics

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/expath/xpath-ng/issues/23, or unsubscribe https://github.com/notifications/unsubscribe-auth/AASIQISHEIBXZJWM6GFQET3SVN4IXANCNFSM4VBLTLMA.

[michaelhkay]

I'm now inclined to have a function fn:parts() which extracts the components of an atomic value as a map, so you write

parts(current-date())?year

or current-date() => parts()?year

It's a little bit harder this way to define the rules in such a way that implementations are allowed to raise an error statically if you do something inappropriate, like implicit-timezone() => parts?hour [should be "hours"], but I expect we can manage.

Michael Kay Saxonica

On 18 Dec 2020, at 16:18, Christian Grün notifications@github.com wrote:

Hi Ghislain, a rather explosive proposal ;) So we could decide between 💥 and 🎆…

One (pretty boring) alternative would be a fn:to-map function, which binds the actual value to a value key and provide additional mappings depending on the type:

to-map(current-date())?year — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/expath/xpath-ng/issues/23#issuecomment-748183595, or unsubscribe https://github.com/notifications/unsubscribe-auth/AASIQIVS5PWIY4EOZ7MS3K3SVN6FNANCNFSM4VBLTLMA.

[ChristianGruen]

I’m in favor of the extra function. It seems better extensible to me as, in principle, the argument of an fn:parts function could also be a sequence, records, or function items (including maps and arrays).