[xquery-talk] Tales of the unexpected version III - Atomization
David Carlisle
davidc at nag.co.uk
Wed Jan 8 04:26:08 PST 2014
On 08/01/2014 12:17, Ihe Onwuka wrote:
list of them, it is not weird at all.
>
> Furthermore atomizing it makes explicitly clear to the programmer whats
> gone on whereas barfing about duplicate attribute nodes when what you
> have coded
>
> <something>{$t/@sex}</__something>
>
> has no explicit duplicate node in sight is bloody confusing until you
> figure out that the duplicates have mysteriously morphed from the group
> by clause. Note this can happen even if your are grouping on something
> other than @sex.
>
>
you seem to be saying you want
<something sex="M"/>
if there is one attribute in the list but to atomise if there are two
and produce
<something>MM</something>
I don't think that would be helpful but as Michael commented it's
irrelevant what either of us think as that's not how it's defined (and
basically it has been defined this way since Xpath 1, 15 years ago)
If you want a single attribute you want
{$t[1]/@sex} <something sex="M"/>
If you want the concatenation of the atomisation of all the attributes
as a text node child, you want
{$t/string(@sex)} <something>MM</something>
If you want the atomisation of a single attribute as a text node child
you want
{$t[1]/@sex} <something>M</something>
I can't imagine a case where you want to decide between those depending
on whether there is a duplicate or not.
David
________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs.
________________________________________________________________________
More information about the talk
mailing list