[xquery-talk] Tales of the unexpected version III - Atomization

[Ihe Onwuka]

The definition of atomization in (for the avoidance of confusion that is
meant to be a link to section 2.4.2 of the XQuery 3.0 spec)

http://www.w3.org/TR/2013/WD-xquery-30-20130723/#id-atomization

looks to me to be saying the opposite of

http://books.google.co.uk/books?id=0Phv5N-cPg8C&pg=PA320&lpg=PA320&dq=xpath+2.0+michael+kay+atomization&source=bl&ots=QECXdBgPqg&sig=N4_kSQc0A--YDxjx4r9AAyPo_Pw&hl=en&sa=X&ei=1fDMUsKDH82ThQe0jIG4AQ&ved=0CDYQ6AEwAQ#v=onepage&q=xpath%202.0%20michael%20kay%20atomization&f=false

The definition in Mike Kay's book looks correct (btw the definition in the
3.0 spec is as was in the 1.0 spec) or at least it makes sense.

As a result of a grouping clause the return of my flowr was bequeathed a
sequence of attribute nodes via the expression $thing/@name. Now I expected
this would be implicitly atomized when I sought to insert it as an
attribute to my return clause but instead eXist barfed some message about
duplicate attribute names. I should mention that it takes a while to figure
that out when your return clause is of the form
<person>($thing/@name)</person> and there are no other attributes in sight.

Anyway, lets get back to the raison d'etre of the thread. If a sequence in
the attribute clause of a return statement isn't a candidate for implicit
atomization - especially one that only became a sequence due to behind the
scenes grouping jiggery pokery.

[Ihe Onwuka]

On Wed, Jan 8, 2014 at 7:10 AM, Ihe Onwuka <***@gmail.com> wrote:

> The definition of atomization in (for the avoidance of confusion that is
> meant to be a link to section 2.4.2 of the XQuery 3.0 spec)
>
> http://www.w3.org/TR/2013/WD-xquery-30-20130723/#id-atomization
>
> looks to me to be saying the opposite of
>
>
> http://books.google.co.uk/books?id=0Phv5N-cPg8C&pg=PA320&lpg=PA320&dq=xpath+2.0+michael+kay+atomization&source=bl&ots=QECXdBgPqg&sig=N4_kSQc0A--YDxjx4r9AAyPo_Pw&hl=en&sa=X&ei=1fDMUsKDH82ThQe0jIG4AQ&ved=0CDYQ6AEwAQ#v=onepage&q=xpath%202.0%20michael%20kay%20atomization&f=false
>
> The definition in Mike Kay's book looks correct (btw the definition in the
> 3.0 spec is as was in the 1.0 spec) or at least it makes sense.
>
> As a result of a grouping clause the return of my flowr was bequeathed a
> sequence of attribute nodes via the expression $thing/@name. Now I expected
> this would be implicitly atomized when I sought to insert it as an
> attribute to my return clause but instead eXist barfed some message about
> duplicate attribute names. I should mention that it takes a while to figure
> that out when your return clause is of the form
> <person>($thing/@name)</person> and there are no other attributes in sight.
>
> Anyway, lets get back to the raison d'etre of the thread. If a sequence in
> the attribute clause of a return statement isn't a candidate for implicit
> atomization - especially one that only became a sequence due to behind the
> scenes grouping jiggery pokery.
>

If a sequence in the attribute clause of a return statement isn't a
candidate for implicit atomization - especially one that only became a
sequence due to behind the scenes grouping jiggery pokery - what is?

[Michael Kay]

Could you explain where you think these two definitions differ?

As far as I can tell, your confusion is about whether atomization is invoked in a particular context, not about what atomization actually does.

In particular, atomization is NOT invoked in XQuery when you use a construct of the form:

>
> <person>($thing/@name)</person>

This is a very common source of confusion and programming mistakes. However, in terms of the specifications you cite:

(a) The XQuery specification (correctly) does not include embedded expressions in its list of contexts where atomization takes place

(b) This construct is specific to XQuery, and therefore outside the scope of my XSLT/XPath book.

Michael Kay
Saxonica

[Ihe Onwuka]

On Wed, Jan 8, 2014 at 9:14 AM, Michael Kay <***@saxonica.com> wrote:

> Could you explain where you think these two definitions differ?
>
>
Your book says atomization is invoked implicitly when a SEQUENCE is used
where ATOMIC VALUES are expected.

The specification says Atomization is applied to a value when the VALUE is
used in a context in which a SEQUENCE of atomic values is required.


> As far as I can tell, your confusion is about whether atomization is
> invoked in a particular context, not about what atomization actually does.
>
>
yup. If I end up (implicitly) with a sequence of nodes in an expression
sourcing an output attribute that looks to me like a SEQUENCE where an
ATOMIC VALUE is expected. Incidentally that was what I was expecting before
eXist barfed on me. Said barfing caused me to look up the XPath data()
function whereupon I saw the definition in your book and thought ...hang
on, this should have been atomized implicitly.



> In particular, atomization is NOT invoked in XQuery when you use a
> construct of the form:
>
> >
> > <person>($thing/@name)</person>
>
> This is a very common source of confusion and programming mistakes.
> However, in terms of the specifications you cite:
>
> (a) The XQuery specification (correctly) does not include embedded
> expressions in its list of contexts where atomization takes place
>
>
I can't begin to fathom the rationale for the exception or the value of
such an exception over the simple rule of atomizing sequences if they
appear in contexts where a value is expected. It seems to me that it is
just demanding the explicit call of the data function (which is exactly
what I put in) for something it could just have easily handled implicitly.


> (b) This construct is specific to XQuery, and therefore outside the scope
> of my XSLT/XPath book.
>
>
My paradigm is the possibly incorrect formula that XQuery 1.0 is a superset
of XPath 2.0 that I have seen bandied about.


> Michael Kay
> Saxonica
> _______________________________________________
> ***@x-query.com
> http://x-query.com/mailman/listinfo/talk
>

[David Carlisle]

On 08/01/2014 09:35, Ihe Onwuka wrote:

> >
> > <person>{$thing/@name}</person>
>

> I can't begin to fathom the rationale for the exception or the value of
> such an exception over the simple rule of atomizing sequences if they
> appear in contexts where a value is expected.

why do you think an atomised value is expected here? would you expect
element nodes


<person>{$thing/name}</person>

to be atomised as well? (They aren't: this would add a sequence of
<name> children to <person>)


> It seems to me that it is
> just demanding the explicit call of the data function (which is exactly
> what I put in) for something it could just have easily handled implicitly.
>

But this construct is designed to add attribute nodes, so implicit
atomization would be undesirable.

> (b) This construct is specific to XQuery, and therefore outside the
> scope of my XSLT/XPath book.
>
>
> My paradigm is the possibly incorrect formula that XQuery 1.0 is a
> superset of XPath 2.0 that I have seen bandied about.
>


XQuery has syntax changes but this is the same as XSLT/XPath 1

<person>
<xsl:copy-of select="$thing/@name"/>
</person>

which would add attribute nodes to the person element.

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

[Ihe Onwuka]

On Wed, Jan 8, 2014 at 11:03 AM, David Carlisle <***@nag.co.uk> wrote:

> On 08/01/2014 09:35, Ihe Onwuka wrote:
>
> >
>> > <person>{$thing/@name}</person>
>>
>>
> I can't begin to fathom the rationale for the exception or the value of
>> such an exception over the simple rule of atomizing sequences if they
>> appear in contexts where a value is expected.
>>
>
> why do you think an atomised value is expected here?


because the value you put in an attribute must be atomic.......


> would you expect element nodes
>
>
> <person>{$thing/name}</person>
>
> to be atomised as well? (They aren't: this would add a sequence of <name>
> children to <person>)
>

......and the value of an element doesn't have to be.


>
>
> > It seems to me that it is
>
>> just demanding the explicit call of the data function (which is exactly
>> what I put in) for something it could just have easily handled implicitly.
>>
>>
> But this construct is designed to add attribute nodes, so implicit
> atomization would be undesirable.


Why? It cannot be a placeholder for anything but an atomic value.

>
>

[David Carlisle]

On 08/01/2014 11:11, Ihe Onwuka wrote:
>
>
>
> On Wed, Jan 8, 2014 at 11:03 AM, David Carlisle <***@nag.co.uk
> <mailto:***@nag.co.uk>> wrote:
>
> On 08/01/2014 09:35, Ihe Onwuka wrote:
>
> >
> > <person>{$thing/@name}</__person>
>
>
> I can't begin to fathom the rationale for the exception or the
> value of
> such an exception over the simple rule of atomizing sequences if
> they
> appear in contexts where a value is expected.
>
>
> why do you think an atomised value is expected here?
>
>
> because the value you put in an attribute must be atomic.......

If you add such a sequence in an attribute constructor then it is
atomized, but here you are copying a sequence of nodes into an element
constructor. In particular you are adding attribute nodes.

>
> would you expect element nodes
>
>
> <person>{$thing/name}</person>
>
> to be atomised as well? (They aren't: this would add a sequence of
> <name> children to <person>)
>
>
> ......and the value of an element doesn't have to be.

You are copying a sequence of nodes so that <person> becodes their
parent, attribute and element nodes are treated similarly.

>
>
>
> > It seems to me that it is
>
> just demanding the explicit call of the data function (which is
> exactly
> what I put in) for something it could just have easily handled
> implicitly.
>
>
> But this construct is designed to add attribute nodes, so implicit
> atomization would be undesirable.
>
>
> Why? It cannot be a placeholder for anything but an atomic value.

No, as shown here it is copying attribute nodes. If $thing is

<foo name="me"/>

then

<person>{$thing/@name}</person>

is

<person name="me"></person>

but


<person>{$thing/@name/string()}</person>

is

<person>me</person>

You are (I think) saying that atomization should be automatic and you
should get the second result, but then you would not be able to copy
attribute (or element) nodes.

David


>
>
>
> ________________________________________________________________________
> This e-mail has been scanned for all viruses by Star.
> ________________________________________________________________________


--
google plus: https:/profiles.google.com/d.p.carlisle

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

[Ihe Onwuka]

On Wed, Jan 8, 2014 at 11:20 AM, David Carlisle <***@nag.co.uk> wrote:

> On 08/01/2014 11:11, Ihe Onwuka wrote:
>
>>
>>
>>
>> On Wed, Jan 8, 2014 at 11:03 AM, David Carlisle <***@nag.co.uk
>> <mailto:***@nag.co.uk>> wrote:
>>
>> On 08/01/2014 09:35, Ihe Onwuka wrote:
>>
>> >
>> > <person>{$thing/@name}</__person>
>>
>>
>>
>> I can't begin to fathom the rationale for the exception or the
>> value of
>> such an exception over the simple rule of atomizing sequences if
>> they
>> appear in contexts where a value is expected.
>>
>>
>> why do you think an atomised value is expected here?
>>
>>
>> because the value you put in an attribute must be atomic.......
>>
>
> If you add such a sequence in an attribute constructor then it is
> atomized, but here you are copying a sequence of nodes into an element
> constructor. In particular you are adding attribute nodes.
>

I may have confused things by getting my brackets wrong. If I did.

<abc cnt='johnny'>be good</abc>/<def>{@cnt}</def>

constructs a def element with a cnt attribute. the expression inside <def>
</def> is an attribute constructor. I expect it to be atomized for the
previously given reasons.


>

>> would you expect element nodes
>>
>>
>> <person>{$thing/name}</person>
>>
>> to be atomised as well? (They aren't: this would add a sequence of
>> <name> children to <person>)
>>
>>
>> ......and the value of an element doesn't have to be.
>>
>
> You are copying a sequence of nodes so that <person> becodes their parent,
> attribute and element nodes are treated similarly.
>

It's not really what they are it's what the receptacle of what I am copying
into expects.


>
>
>>
>>
>> > It seems to me that it is
>>
>> just demanding the explicit call of the data function (which is
>> exactly
>> what I put in) for something it could just have easily handled
>> implicitly.
>>
>>
>> But this construct is designed to add attribute nodes, so implicit
>> atomization would be undesirable.
>>
>>
>> Why? It cannot be a placeholder for anything but an atomic value.
>>
>
> No, as shown here it is copying attribute nodes. If $thing is
>
> <foo name="me"/>
>
> then
>
> <person>{$thing/@name}</person>
>
> is
>
> <person name="me"></person>
>

exactly


>
> but
>
>
> <person>{$thing/@name/string()}</person>
>
> is
>
> <person>me</person>
>
>
so by putting the string() function on the end it is no longer
constrtucting an attribute. I have no problem with that.



> You are (I think) saying that atomization should be automatic and you
> should get the second result, but then you would not be able to copy
> attribute (or element) nodes.
>
>

No. I am saying that if the expression is an attrtibute constructor then
atomization should be atomic.

<person>{$thing/@name/string()}</person>

is not an attribute constructor. It is an expression derived from an
attribute.

[David Carlisle]

On 08/01/2014 11:36, Ihe Onwuka wrote:
> No. I am saying that if the expression is an attrtibute constructor then
> atomization should be atomic.


OK so I'm completely lost as I don't understand what you expect.

<person>{$thing/@name}</person>

simply copies an attribute node from wherever it is to the newly
constructed <person> element. Atomization is just not relevant, the node
is already an attribute node (with a value that is atomic) the node is
just copied to the tree being generated.

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

[Ihe Onwuka]

On Wed, Jan 8, 2014 at 11:44 AM, David Carlisle <***@nag.co.uk> wrote:

> On 08/01/2014 11:36, Ihe Onwuka wrote:
>
>> No. I am saying that if the expression is an attrtibute constructor then
>> atomization should be atomic.
>>
>
>
> OK so I'm completely lost as I don't understand what you expect.
>
> <person>{$thing/@name}</person>
>
> simply copies an attribute node from wherever it is to the newly
> constructed <person> element. Atomization is just not relevant, the node is
> already an attribute node (with a value that is atomic) the node is just
> copied to the tree being generated.
>
>
<things>
<thing name="Peter" sex="M"/>
<thing name="Pan" sex="M"/>
<thing name="Jemma" sex="F"/>
<thing name="Janice" sex="F"/>
<things>

for $t in things/thing
group by $sex:=$t/@sex
return <something>{$t/@sex}</something>

the effect of the group by turns {$t/@sex} into a sequence of attribute
nodes and the processor (at least eXist) will barf about duplicate
attributes instead of atomizing them. Why barf - duplicate atttributes are
not allowed and demand an explicit atomization?



It is possible that thing/@name may be a sequence of nodes by the time it
reaches

>
>

[David Carlisle]

On 08/01/2014 11:55, Ihe Onwuka wrote:
>
> for $t in things/thing group by $sex:=$t/@sex return
> <something>{$t/@sex}</something>
>
> the effect of the group by turns {$t/@sex} into a sequence of
> attribute nodes and the processor (at least eXist) will barf about
> duplicate attributes instead of atomizing them. Why barf - duplicate
> atttributes are not allowed and demand an explicit atomization?


because atomising would just be weird.

If $t/sex is a single sex="M" attribute node then it is not atomized it
is simply copied to <something> producing

<something sex="M"/>

If (as in your example) it is a sequence of two attribute nodes
sex="M" sex="M"
then as you can not have two attributes on the <something> element it is
an XQuery error. (XSLT takes a different route and just uses the last)

If the sequence were atomised then you would get

<something>MM</something>


as for

<something>{$t/string(@sex)}</something>

which would be pretty strange to happen by default.

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

[Ihe Onwuka]

On Wed, Jan 8, 2014 at 12:07 PM, David Carlisle <***@nag.co.uk> wrote:

> On 08/01/2014 11:55, Ihe Onwuka wrote:
>
>>
>> for $t in things/thing group by $sex:=$t/@sex return
>> <something>{$t/@sex}</something>
>>
>> the effect of the group by turns {$t/@sex} into a sequence of
>> attribute nodes and the processor (at least eXist) will barf about
>> duplicate attributes instead of atomizing them. Why barf - duplicate
>> atttributes are not allowed and demand an explicit atomization?
>>
>
>
> because atomising would just be weird.
>
>
It's looks weird because I used a crap example but in my real scenario it
is exactly what I wanted it to do. In fact if your plan is to subsequently
count and/or union/interstect the atomized values or return a the 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.

[David Carlisle]

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

[Ihe Onwuka]

On Wed, Jan 8, 2014 at 12:26 PM, David Carlisle <***@nag.co.uk> wrote:

> 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"/>
>
>
No I'm not. I want

<someting sex='M M"/>

then I could count them.

and if it was

<foo bar="...."/> where the sequence of @bar's take on several distinct
overlapping values I may want to union or interesect them

and if @bar didn't taken on overlapping values I may want to return them as
a list.

I don't know how much clearer I can make this.


> 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. ______________________________
> __________________________________________
>

[Ihe Onwuka]

On Wed, Jan 8, 2014 at 12:32 PM, Ihe Onwuka <***@gmail.com> wrote:

>
> On Wed, Jan 8, 2014 at 12:26 PM, David Carlisle <***@nag.co.uk> wrote:
>
>> 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"/>
>>
>>
> No I'm not. I want
>
> <someting sex='M M"/>
>
> then I could count them.
>
> and if it was
>
> <foo bar="...."/> where the sequence of @bar's take on several distinct
> overlapping values I may want to union or interesect them
>
> and if @bar didn't taken on overlapping values I may want to return them
> as a list.
>
> I don't know how much clearer I can make this.
>
>
actually I can make it clearer.

Having started with 3 differe

<review person="John" product="xsl book"/>
<review person="John" product="perl book"/>
<review person="Janet" product="perl book/>
<review person="chris" product="ruby book"/>
<review person="chris" product="xsl book"/>

and I group by @person and get

<review person="John" product="xsl book perl book"/>
<review person ="Janet" product="perl book"/>
<review person="chris" product="ruby book xsl book"/>

Well it just might be that subsequently I want the spanned set of
everything thats ever been reviewed and/or I want count of all the
products reviewed by person alongside a list of them . It might also be
that the content of the review element is the actual review so I want
don't want to pollute it with a list and would rather squirrel away the
sequence of products in an attribute.

Now thats me done. If it sounds weird to you , well the client doesn't
think so.

[David Carlisle]

On 08/01/2014 12:55, Ihe Onwuka wrote:
> Now thats me done. If it sounds weird to you , well the client doesn't
> think so.

The client requirements are reasonable, but the code did not match that
requirement.

The product attribute in your desired result is not a copy of any
attribute in the source so you need to use an attribute constructor.

<review product="{$t/@product}">

_would_ be atomised exactly as you wish as, the content of an attribute
constructor is implicitly atomized. You were copying into the content of
an element constructor, and the contents of element constructors are not
atomized by default.

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

[Ihe Onwuka]

On Wed, Jan 8, 2014 at 1:04 PM, David Carlisle <***@nag.co.uk> wrote:

> On 08/01/2014 12:55, Ihe Onwuka wrote:
>
>> Now thats me done. If it sounds weird to you , well the client doesn't
>> think so.
>>
>
> The client requirements are reasonable, but the code did not match that
> requirement


You posit you know what my client wants because I posted an example
(where's the emoticon for two raised eyebrows when you need it).



> The product attribute in your desired result is not a copy of any
> attribute in the source so you need to use an attribute constructor.
>
> <review product="{$t/@product}">
>
> _would_ be atomised exactly as you wish as, the content of an attribute
> constructor is implicitly atomized. You were copying into the content of an
> element constructor, and the contents of element constructors are not
> atomized by default.
>
>
I don't care David, because you miss the whole point.

The biggest problem is the confusing error message that results telling you
that you have duplicate nodes when you haven't explicitly coded any.

As I said earlier if attributes created in element constructors (happy
now?) were atomized then the programmer could see what has gone on and
accept or correct accordingly.

As it is unless he understands the effect the group by clause can have
(this is the same group by clause that Dr Kay said he was raising a
specification bug about yesterday) he is going to be baffled as to why he
is getting an error telling him he has duplicate attribute nodes because he
doesn't think he's coded any.

[David Lee]

----------
As it is unless he understands the effect the group by clause can have (this is the same group by clause that Dr Kay said he was raising a specification bug about yesterday) he is going to be baffled as to why he is getting an error telling him he has duplicate attribute nodes because he doesn't think he's coded any.

Brought up to another level ... I think this is generally true.
If a person does something that tells a system to do something very different than what the person thought was being asked,
And especially if the "error" is far enough out of context then error messages can be very confusing.

If the computer had enough context, and perhaps AI and ESP and could deduce "OH you thought you were doing THIS but you did THAT instead and I didn't like that" it could produce better messaging.

It's a noble but tough problem ... Its hard enough for computers to reliably report on things that go wrong,
To ask them to diagnose what you thought you were doing that caused it to go wrong is asking a lot.
Someday maybe they will be able to do that.
In the meantime us computer users have to struggle with a literally mindless machine as best we can.


-David

----------------------------------------
David A. Lee
***@calldei.com<mailto:***@calldei.com>
http://www.xmlsh.org

[Michael Kay]

On 8 Jan 2014, at 13:44, David Lee <***@calldei.com> wrote:

> ----------
> As it is unless he understands the effect the group by clause can have (this is the same group by clause that Dr Kay said he was raising a specification bug about yesterday) he is going to be baffled as to why he is getting an error telling him he has duplicate attribute nodes because he doesn't think he's coded any.

The bug I raised isn't against the group by clause. It's against the use of the terms "initial clause" and "intermediate clause" with two subtly different meanings. Most people will get the correct meaning from the context, but it could certainly be made clearer.
>


> Brought up to another level … I think this is generally true.
> If a person does something that tells a system to do something very different than what the person thought was being asked,
> And especially if the “error” is far enough out of context then error messages can be very confusing.
>
> If the computer had enough context, and perhaps AI and ESP and could deduce “OH you thought you were doing THIS but you did THAT instead and I didn’t like that” it could produce better messaging.
>
> It’s a noble but tough problem … Its hard enough for computers to reliably report on things that go wrong,
> To ask them to diagnose what you thought you were doing that caused it to go wrong is asking a lot.
> Someday maybe they will be able to do that.
> In the meantime us computer users have to struggle with a literally mindless machine as best we can.
>

Yes. There is of course a lot that can be done to improve error messages. Sometimes implementors don't go to enough trouble to think about the possible causes of an error and the opportunities for tailoring messages. For example, if a schema requires the next element to be one of (A, B, or C), and you supply something with the right local name to match B but with a different namespace, then rather than giving the baffling message "Found B, expected A, B, or C", it's quite possible to say "Element B is in namespace foo, it should be in namespace bar".

Very often this happens because the person composing the error message never actually uses the product themself, and therefore fails to realise how much could be done to make users lives easier.

A very difficult thing when designing error messages is to assess how well the reader understands the specification, in two areas: (a) knowing the technical terminology, and (b) knowing what is supposed to happen. In this case the main problem is (b); the user expects an attribute node to be atomized, when the specification says that it isn't atomized, and this misunderstanding of the spec is the root cause of the error that manifests itself as adding duplicate attributes to an element. It would certainly be possible in principle (though not easy) to detect that the duplicate attributes result from evaluation of an embedded expression, and to add something like "Two attributes with the same name are being added to the XYZ element. Perhaps the attribute node should be atomized by calling the data() function?". However, when the implementor's guess is wrong, such messages can be even more misleading than the original.

(Doing a deeper analysis that traces the root cause to being something to do with grouping is probably way too hard and too speculative.)

The only real way of improving usability is to design a language which avoids surprises, even when users don't read the spec. This particular feature of XQuery (the fact that embedded expressions aren't atomized) is certainly one that catches users out quite often. It's too late to change it of course, and even then it's not clear what a better design would look like. In XSLT 3.0 we have introduced a similar construct (content templates) and decided that these should always be atomized, which we can do because we have the <xsl:copy-of> instruction for the alternate behaviour. So at least we're learning from mistakes.

Michael Kay
Saxonica

[Andrew Welch]

> I don't care David, because you miss the whole point.

Has DC misunderstood something? If so we should print and frame this
thread for posterity.

[Ihe Onwuka]

We were having an orthogonal conversation.

He didn't care about the effect and context of the resulting error message
and I didn't care about the distinction between attribute constructors and
attributes created as part of element constructors.


On Wed, Jan 8, 2014 at 1:59 PM, Andrew Welch <***@gmail.com>wrote:

> > I don't care David, because you miss the whole point.
>
> Has DC misunderstood something? If so we should print and frame this
> thread for posterity.
>

[Ihe Onwuka]

It seems there has been a fair amount of confusion. Let me try and clear
some of it up. I had solved this problem for myself before the original
post.

I had something like

return <review>{$t/@name}</review> following a group by.

I had intended it to create an atomized @name attribute in the review
element.

Instead I got a duplicate attribute node error and my instant reaction was
WTF. I had already cut and pasted ready to file an error report but thanks
to my group by session with Doc K yesterday I figured out there were
duplicates because of the effect of the group by.

So then I went to look up the data function in Doc K's book and it says

"Atomization is a process that is invoked implicitly when a sequence
containing nodes is used in a context where atomic values are expected".

And I thought - that fits what I am doing. I have (thanks to group by) a
sequence that contains nodes and I am using it in a context where (to my
understanding) atomic values are expected - because it is going to end up
(by whatever process) as an attribute node. Therefore I should have had the
benefit of implicit atomization. Unless I did not read down far enough Doc
K's book, it doesn't say anything about any distinction in how these
attribute nodes are created. Anyway the data() function which I now know is
characterised as explicit atomization did the trick - I was all fine and
dandy.

I decided to check the spec because from reading Doc K I it looked like I
should have had a slam dunk implicit atomization. When I did so it looked
like it was saying (and still does to me) the opposite to what Doc K was
saying in his book. So the primary motive for the thread was - I've solved
my problem but think I should be getting implicit atomization here. Sub
motives were clarification of the perceived discrepancy between Doc K's
book which I understood and the spec which I didn't. I also hinted at
concern over the circumstances of the error message (because that for me
lies at the root of it).

I should note that Section 2.4.2 of the spec that deals with atomization
doesn't say anything about any of the distinctions mentioned in this
thread. What it does says is

Atomization is used in processing the following types of expressions:
................................................................................
................................................................................

-

Constructor expressions for various kinds of nodes

and there are no footnotes or superscripts directing you or advising you of
a need to read anything else on the subject.

All the while I was posting examples I had already gotten a working
solution - maybe I should have just gotten on with my work.

Hopefully that only leaves the Chinese burn as possible source of confusion
for those who may have had a different cultural childhood. Better to give
than to receive.











On Wed, Jan 8, 2014 at 2:06 PM, Ihe Onwuka <***@gmail.com> wrote:

> We were having an orthogonal conversation.
>
> He didn't care about the effect and context of the resulting error message
> and I didn't care about the distinction between attribute constructors and
> attributes created as part of element constructors.
>
>
> On Wed, Jan 8, 2014 at 1:59 PM, Andrew Welch <***@gmail.com>wrote:
>
>> > I don't care David, because you miss the whole point.
>>
>> Has DC misunderstood something? If so we should print and frame this
>> thread for posterity.
>>
>
>

[David Carlisle]

On 08/01/2014 15:38, Ihe Onwuka wrote:
> because it is going to end up (by whatever process) as an attribute
> node.


That seems to be the cause of your confusion (and your misreading of the
spec and Mike Kay's book) If you go <foo>{$d/@*}</foo> You are _not_
copying nodes to a context where atomic values are expected, you are
copying them to an element node constructor, which is expecting nodes.

If the sequence were atomized (implicitly or by explicit use of data()
or string() then it would not "end up by any process as an attribute
node", it would make text node child of the element (which is why I
assumed originally that was what you intended to generate).

Implicit atomization would do the same as

<foo>{$d/@*/data()}</foo>

and the odd thing is you have said repeatedly that data() solved your
problem, but that will not generate any attribute nodes, the values of
the attributes will be concatenated as text node child of <foo>.


Had you gone <foo bar="{$d/@*}"/> then you are copying to such a
context, and atomization would be automatic and you would get the result
you want.

The FLWOR expression and group by clause are not really
relevant to the issue, you get the same behaviour (and same error
messages) without any grouping.

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

[Ihe Onwuka]

On Wed, Jan 8, 2014 at 4:22 PM, David Carlisle <***@nag.co.uk> wrote:

> On 08/01/2014 15:38, Ihe Onwuka wrote:
>
>> because it is going to end up (by whatever process) as an attribute
>> node.
>>
>
>
> That seems to be the cause of your confusion (and your misreading of the
> spec and Mike Kay's book)


Ok. What sections of Mike Kay's book and the spec didn't I read that
conveyed the information you just gave and what references to them did I
miss.

[John Snelson]

On 08/01/14 16:25, Ihe Onwuka wrote:
>
> On Wed, Jan 8, 2014 at 4:22 PM, David Carlisle <***@nag.co.uk
> <mailto:***@nag.co.uk>> wrote:
>
> On 08/01/2014 15:38, Ihe Onwuka wrote:
>
> because it is going to end up (by whatever process) as an attribute
> node.
>
>
>
> That seems to be the cause of your confusion (and your misreading of the
> spec and Mike Kay's book)
>
>
> Ok. What sections of Mike Kay's book

Mike Kay's book doesn't cover XQuery.

> and the spec didn't I read that conveyed the information you just gave and what references to them did I
> miss.

http://www.w3.org/TR/xquery-30/#id-content

John

--
John Snelson, Lead Engineer http://twitter.com/jpcs
MarkLogic Corporation http://www.marklogic.com

[Ihe Onwuka]

and that referenced from section 2.4.2 where?

or was I supposed to have sussed that from seeing


-

Constructor expressions for various kinds of nodes

if I was....I guess it's my bad.


On Wed, Jan 8, 2014 at 4:29 PM, John Snelson <***@marklogic.com>wrote:

> On 08/01/14 16:25, Ihe Onwuka wrote:
>
>>
>> On Wed, Jan 8, 2014 at 4:22 PM, David Carlisle <***@nag.co.uk
>> <mailto:***@nag.co.uk>> wrote:
>>
>> On 08/01/2014 15:38, Ihe Onwuka wrote:
>>
>> because it is going to end up (by whatever process) as an
>> attribute
>> node.
>>
>>
>>
>> That seems to be the cause of your confusion (and your misreading of
>> the
>> spec and Mike Kay's book)
>>
>>
>> Ok. What sections of Mike Kay's book
>>
>
> Mike Kay's book doesn't cover XQuery.
>
>
> and the spec didn't I read that conveyed the information you just gave
>> and what references to them did I
>> miss.
>>
>
> http://www.w3.org/TR/xquery-30/#id-content
>
>
> John
>
> --
> John Snelson, Lead Engineer http://twitter.com/jpcs
> MarkLogic Corporation http://www.marklogic.com
> _______________________________________________
> ***@x-query.com
> http://x-query.com/mailman/listinfo/talk
>

[John Snelson]

In the XQuery 3.0 specification, section 3.9.1 describes direct element
constructors. A sub-section inside that (3.9.1.3 Content) describes how
to process the content of direct element constructors. This section is
also linked from "3.9.3.1 Computed Element Constructors".

http://www.w3.org/TR/xquery-30/#id-content

The XQuery spec is not always straight forward to read, but I think it's
clear in this case. However the XQuery spec is not meant to be a
tutorial in XQuery - there are better places to learn XQuery.

John

On 08/01/14 16:39, Ihe Onwuka wrote:
> and that referenced from section 2.4.2 where?
>
> or was I supposed to have sussed that from seeing
>
> *
>
> Constructor expressions for various kinds of nodes
>
> if I was....I guess it's my bad.
>
>
> On Wed, Jan 8, 2014 at 4:29 PM, John Snelson <***@marklogic.com
> <mailto:***@marklogic.com>> wrote:
>
> On 08/01/14 16:25, Ihe Onwuka wrote:
>
>
> On Wed, Jan 8, 2014 at 4:22 PM, David Carlisle <***@nag.co.uk
> <mailto:***@nag.co.uk>
> <mailto:***@nag.co.uk <mailto:***@nag.co.uk>>> wrote:
>
> On 08/01/2014 15:38, Ihe Onwuka wrote:
>
> because it is going to end up (by whatever process) as
> an attribute
> node.
>
>
>
> That seems to be the cause of your confusion (and your
> misreading of the
> spec and Mike Kay's book)
>
>
> Ok. What sections of Mike Kay's book
>
>
> Mike Kay's book doesn't cover XQuery.
>
>
> and the spec didn't I read that conveyed the information you
> just gave and what references to them did I
> miss.
>
>
> http://www.w3.org/TR/xquery-__30/#id-content
> <http://www.w3.org/TR/xquery-30/#id-content>
>
>
> John
>
> --
> John Snelson, Lead Engineer http://twitter.com/jpcs
> MarkLogic Corporation http://www.marklogic.com
> _________________________________________________
> ***@x-query.com <mailto:***@x-query.com>
> http://x-query.com/mailman/__listinfo/talk
> <http://x-query.com/mailman/listinfo/talk>
>
>


--
John Snelson, Lead Engineer http://twitter.com/jpcs
MarkLogic Corporation http://www.marklogic.com

[Ihe Onwuka]

You would have thought that a person using it as a tutorial would have
read alot more of it rather than a single section.

But let me agree with you. Michael Brundage's book is so good I have two
copies I also like XQuery by the Experts .


On Wed, Jan 8, 2014 at 4:40 PM, John Snelson <***@marklogic.com>wrote:

> In the XQuery 3.0 specification, section 3.9.1 describes direct element
> constructors. A sub-section inside that (3.9.1.3 Content) describes how to
> process the content of direct element constructors. This section is also
> linked from "3.9.3.1 Computed Element Constructors".
>
> http://www.w3.org/TR/xquery-30/#id-content
>
> The XQuery spec is not always straight forward to read, but I think it's
> clear in this case. However the XQuery spec is not meant to be a tutorial
> in XQuery - there are better places to learn XQuery.
>
> John
>
>
> On 08/01/14 16:39, Ihe Onwuka wrote:
>
>> and that referenced from section 2.4.2 where?
>>
>> or was I supposed to have sussed that from seeing
>>
>> *
>>
>>
>> Constructor expressions for various kinds of nodes
>>
>> if I was....I guess it's my bad.
>>
>>
>> On Wed, Jan 8, 2014 at 4:29 PM, John Snelson <***@marklogic.com
>> <mailto:***@marklogic.com>> wrote:
>>
>> On 08/01/14 16:25, Ihe Onwuka wrote:
>>
>>
>> On Wed, Jan 8, 2014 at 4:22 PM, David Carlisle <***@nag.co.uk
>> <mailto:***@nag.co.uk>
>> <mailto:***@nag.co.uk <mailto:***@nag.co.uk>>> wrote:
>>
>> On 08/01/2014 15:38, Ihe Onwuka wrote:
>>
>> because it is going to end up (by whatever process) as
>> an attribute
>> node.
>>
>>
>>
>> That seems to be the cause of your confusion (and your
>> misreading of the
>> spec and Mike Kay's book)
>>
>>
>> Ok. What sections of Mike Kay's book
>>
>>
>> Mike Kay's book doesn't cover XQuery.
>>
>>
>> and the spec didn't I read that conveyed the information you
>> just gave and what references to them did I
>> miss.
>>
>>
>> http://www.w3.org/TR/xquery-__30/#id-content
>>
>> <http://www.w3.org/TR/xquery-30/#id-content>
>>
>>
>> John
>>
>> --
>> John Snelson, Lead Engineer http://twitter.com/jpcs
>> MarkLogic Corporation http://www.marklogic.com
>> _________________________________________________
>> ***@x-query.com <mailto:***@x-query.com>
>> http://x-query.com/mailman/__listinfo/talk
>> <http://x-query.com/mailman/listinfo/talk>
>>
>>
>>
>
> --
> John Snelson, Lead Engineer http://twitter.com/jpcs
> MarkLogic Corporation http://www.marklogic.com
>

[David Carlisle]

On 08/01/2014 16:39, Ihe Onwuka wrote:
> and that referenced from section 2.4.2 where?
>
> or was I supposed to have sussed that from seeing
>
> *
>
> Constructor expressions for various kinds of nodes
>
> if I was....I guess it's my bad.
>

That perhaps but more to the point it says in the first line

> Atomization is applied to a value when the value is used in a context
> in which a sequence of atomic values is required.


and the content of an element constructor is (fairly obviously I would
have thought) _not_ a context where a sequence of atomic values is required.


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

[Ihe Onwuka]

I guess what I said about the error message didn't resonate.


On Wed, Jan 8, 2014 at 4:47 PM, David Carlisle <***@nag.co.uk> wrote:

> On 08/01/2014 16:39, Ihe Onwuka wrote:
>
>> and that referenced from section 2.4.2 where?
>>
>> or was I supposed to have sussed that from seeing
>>
>> *
>>
>>
>> Constructor expressions for various kinds of nodes
>>
>> if I was....I guess it's my bad.
>>
>>
> That perhaps but more to the point it says in the first line
>
> Atomization is applied to a value when the value is used in a context
>> in which a sequence of atomic values is required.
>>
>
>
> and the content of an element constructor is (fairly obviously I would
> have thought) _not_ a context where a sequence of atomic values is
> required.
>
>
>
> 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. ______________________________
> __________________________________________
>

[David Carlisle]

On 08/01/2014 16:51, Ihe Onwuka wrote:
> I guess what I said about the error message didn't resonate.

The error message seems clear and appropriate: if you copy two
attributes with the same name to the same element you get an error. (It
could be defined not to be an error, XSLT as I mentioned ignores all of
the copied nodes except the last) but it is hard to see how atomization
(the subject line you chose for this thread) is related to that.


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

[Andrew Welch]

On 8 January 2014 16:59, David Carlisle <***@nag.co.uk> wrote:
> On 08/01/2014 16:51, Ihe Onwuka wrote:
>>
>> I guess what I said about the error message didn't resonate.
>
>
> The error message seems clear and appropriate: if you copy two
> attributes with the same name to the same element you get an error. (It
> could be defined not to be an error, XSLT as I mentioned ignores all of
> the copied nodes except the last) but it is hard to see how atomization
> (the subject line you chose for this thread) is related to that.

Indeed - this is ultimately all boils down to the gotcha of xquery
returning element and attribute nodes instead of the string values of
those nodes ala xslt. (my test framework uses xquery in the junit
tests and I still often get caught by this when I forget /string(.) on
the end of simple xpaths)

Like all gotchas you will get got until you know about them. The
thing is, xquery has a load more, so if they are all played out like
this it should be fun.



--
Andrew Welch
http://andrewjwelch.com

[Ihe Onwuka]

On Wed, Jan 8, 2014 at 5:13 PM, Andrew Welch <***@gmail.com>wrote:

> On 8 January 2014 16:59, David Carlisle <***@nag.co.uk> wrote:
> Like all gotchas you will get got until you know about them. The
> thing is, xquery has a load more, so if they are all played out like
> this it should be fun.
>
>

[David Carlisle]

On 08/01/2014 16:25, Ihe Onwuka wrote:
> Ok. What sections of Mike Kay's book and the spec didn't I read that
> conveyed the information you just gave and what references to them
> did I miss.

That's really the only reason I carried on with the thread. To see if
there are any parts of the spec that can be clarified. (Not that I have
any input to that, other than bug reports).

It is hard to see how (from either source) you came to the conclusion
that atomization would happen here so I can't really guess which parts
of either text could be clarified. Also since you haven't shown how you
used data() in any way that works (and I can't think of one) I can't
suggest what part of the text would tell you to use data in the way that
you say works.

The issue is that you want to generate an attribute, so you should use
an attribute constructor. If you do that then any data you supply to the
constructor is implicitly atomized and the resulting space separated
sequence used as the attribute value.

You didn't use an attribute constructor and so didn't get the result you
expected, but I am not sure what you expect the spec to say.

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

[Ihe Onwuka]

I'm pretty sure I'm not the only one for whom this language is a means to
an end. I think I know what to use it for, I have a mental model of the
language and enough curiosity to ask questions when things stray beyond it.
I have zero interest in establishing a reputation as an XQuery developer
whether by challenging the spec or in any other way but I have a tenacious
kind of curiosity that may annoy an author of something I'm asking about.
Meh!. XQuery happens to be a good fit for what I am doing at the moment
and it bailed me out a couple of days ago when I tried to transform
something that was too big for XSLT to swallow. I like it. I'm happy I know
enough to get things done and solve my own problems with it. Thus I far
have been able to accomplish whatever I needed on my own steam barring
yesterdays intervention on grouping by Doc K.

I'm also sure I'm not the only one whose primary interaction with the spec
consists of sporadic infrequent googling a phrase zeroing in and zeroing
out. If for example something like grouping was vexing me I have a limited
threshold for the arcane or the abstruse and I'd be inclined to dump the
thing into a relational database and do my aggregating in SQL. Despite
owning some XQuery books I'm quite relaxed about being labelled a person
who thinks XQuery is a glorified XPath and will happily confess to
ignorance of nuances between them. I will tend to extrapolate from what I
know about a similar thing and am not and will not be shy about asking
about differences along the way. Thats how I augment my mental model of the
language and especially when you are using the bleeding edge release it far
far better to ask these questions.


On Wed, Jan 8, 2014 at 5:04 PM, W.S. Hager <***@gmail.com> wrote:

> I agree with your critique but xquery != xml. In xquery anything is
> sequable, making it a powerful functional language. That the serialization
> will sometimes yield minor discrepancies is a known fact programmers deal
> with on daily basis.
>
> Thanks for the enlightening discussion.
>
> Wouter
> Op 8 jan. 2014 17:27 schreef "Ihe Onwuka" <***@gmail.com>:
>
>>
>> On Wed, Jan 8, 2014 at 4:22 PM, David Carlisle <***@nag.co.uk> wrote:
>>
>>> On 08/01/2014 15:38, Ihe Onwuka wrote:
>>>
>>>> because it is going to end up (by whatever process) as an attribute
>>>> node.
>>>>
>>>
>>>
>>> That seems to be the cause of your confusion (and your misreading of the
>>> spec and Mike Kay's book)
>>
>>
>> Ok. What sections of Mike Kay's book and the spec didn't I read that
>> conveyed the information you just gave and what references to them did I
>> miss.
>>
>>
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
>> Pro!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Exist-open mailing list
>> Exist-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/exist-open
>>
>>

[Geert Josten]

Hi Ihe,



I guess most people (including me) got confused because you started off
with discussing Atomization, but there is no atomization here (as others
tried to point out). I read you mentioning that attributes only contain
atomic values, but in this case the attributes are the source, not the
target. The target is the review element, and that can hold elements,
attributes, as well as atomic values. Only if the target cannot hold nodes,
atomization takes place. In this case it wasn’t necessary, and therefore
skipped. The effect is that the sequence of $thing/@name attributes is
being inserted into the review element, but you cannot insert an attribute
with the same name more than once to a single parent element. Hence the
error message..



To me the error message is clear enough, but perhaps that is because of my
long history with XML?



Cheers,

Geert



*Van:* talk-***@x-query.com [mailto:talk-***@x-query.com] *Namens *Ihe
Onwuka
*Verzonden:* woensdag 8 januari 2014 16:39
*Aan:* Andrew Welch
*CC:* ***@x-query.com; exist-***@lists.sourceforge.net ml; David Carlisle
*Onderwerp:* Re: [xquery-talk] Tales of the unexpected version III -
Atomization



It seems there has been a fair amount of confusion. Let me try and clear
some of it up. I had solved this problem for myself before the original
post.



I had something like



return <review>{$t/@name}</review> following a group by.



I had intended it to create an atomized @name attribute in the review
element.



Instead I got a duplicate attribute node error and my instant reaction was
WTF. I had already cut and pasted ready to file an error report but thanks
to my group by session with Doc K yesterday I figured out there were
duplicates because of the effect of the group by.



So then I went to look up the data function in Doc K's book and it says



"Atomization is a process that is invoked implicitly when a sequence
containing nodes is used in a context where atomic values are expected".



And I thought - that fits what I am doing. I have (thanks to group by) a
sequence that contains nodes and I am using it in a context where (to my
understanding) atomic values are expected - because it is going to end up
(by whatever process) as an attribute node. Therefore I should have had the
benefit of implicit atomization. Unless I did not read down far enough Doc
K's book, it doesn't say anything about any distinction in how these
attribute nodes are created. Anyway the data() function which I now know is
characterised as explicit atomization did the trick - I was all fine and
dandy.



I decided to check the spec because from reading Doc K I it looked like I
should have had a slam dunk implicit atomization. When I did so it looked
like it was saying (and still does to me) the opposite to what Doc K was
saying in his book. So the primary motive for the thread was - I've solved
my problem but think I should be getting implicit atomization here. Sub
motives were clarification of the perceived discrepancy between Doc K's
book which I understood and the spec which I didn't. I also hinted at
concern over the circumstances of the error message (because that for me
lies at the root of it).



I should note that Section 2.4.2 of the spec that deals with atomization
doesn't say anything about any of the distinctions mentioned in this
thread. What it does says is



Atomization is used in processing the following types of expressions:

................................................................................

................................................................................

· Constructor expressions for various kinds of nodes

and there are no footnotes or superscripts directing you or advising you of
a need to read anything else on the subject.



All the while I was posting examples I had already gotten a working
solution - maybe I should have just gotten on with my work.



Hopefully that only leaves the Chinese burn as possible source of confusion
for those who may have had a different cultural childhood. Better to give
than to receive.





















On Wed, Jan 8, 2014 at 2:06 PM, Ihe Onwuka <***@gmail.com> wrote:

We were having an orthogonal conversation.



He didn't care about the effect and context of the resulting error message
and I didn't care about the distinction between attribute constructors and
attributes created as part of element constructors.



On Wed, Jan 8, 2014 at 1:59 PM, Andrew Welch <***@gmail.com>
wrote:

> I don't care David, because you miss the whole point.

Has DC misunderstood something? If so we should print and frame this
thread for posterity.

[Geert Josten]

> Has DC misunderstood something? If so we should print and frame this
> thread for posterity.

:-)

[Ihe Onwuka]

On Wed, Jan 8, 2014 at 12:43 PM, David Carlisle <***@nag.co.uk> wrote:

> On 08/01/2014 12:32, Ihe Onwuka wrote:
>
>> No I'm not. I want
>>
>> <something sex='M M"/>
>>
>>
>> then I could count them.
>>
>
> Oh wow I never guessed you meant you wanted that:-) (You said you were
> adding data() which would make what I suggested: <something>MM<something/>
>
>
It's just an example that I had to concoct because you keep inventing
scenarios to make your argument. I don't know why you would want to engage
me in an argument on my code and my scenario when I know exactly why I want
to do something and you don't. To me it's an argument that can only ever
have one outcome.

In the real scenario I used the data() function to get what I wanted, but
I'm done talking about this now.

[Michael Kay]

> I expect it to be atomized for the previously given reasons.

It's a common expectation, but it's wrong. There is nothing in the spec that encourages you to have such an expectation; you're just saying that if you had designed the language, you would have done it differently.

When the spec talks about an atomic value being expected, it's talking about expectations that are informed by reading the spec, not expectations based on how you would have liked the language to behave.

Michael Kay
Saxonica

[Ihe Onwuka]

It's what I expected. I haven't seen a rational explanation to expect
anything different.

If it doesn't do that it's ok, but I wouldn't expect a language to give an
error where it could do something different.

The spec might say this will give you an error unless f you type it with
one hand while somebody is giving you a Chinese burn.

Ok thats what you have to live by, but don't have a go at someone for
trying to figure out why it makes sense.


On Wed, Jan 8, 2014 at 11:58 AM, Michael Kay <***@saxonica.com> wrote:

> > I expect it to be atomized for the previously given reasons.
>
> It's a common expectation, but it's wrong. There is nothing in the spec
> that encourages you to have such an expectation; you're just saying that if
> you had designed the language, you would have done it differently.
>
> When the spec talks about an atomic value being expected, it's talking
> about expectations that are informed by reading the spec, not expectations
> based on how you would have liked the language to behave.
>
> Michael Kay
> Saxonica
> _______________________________________________
> ***@x-query.com
> http://x-query.com/mailman/listinfo/talk
>

[Ihe Onwuka]

On Wed, Jan 8, 2014 at 11:48 AM, David Carlisle <***@nag.co.uk> wrote:

> On 08/01/2014 11:36, Ihe Onwuka wrote:
> > <abc cnt='johnny'>be good</abc>/<def>{@cnt}</def>
>
>> the expression inside <def> </def> is an attribute constructor.
>>
>
> No it's not an attribute constructor the attribute node is already
> constructed when the abc element was constructed. It is just copying an
> existing node.
>
>
It created an attribute in the <def> element and the value that attribute
takes can never be anything but atomic.

That's all I care about.