[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