On Wed, Jan 8, 2014 at 7:10 AM, Ihe Onwuka <[email protected]> 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?
_______________________________________________ [email protected] http://x-query.com/mailman/listinfo/talk
