- From: Peter Fankhauser <fankhaus@ipsi.fraunhofer.de>
- Date: Wed, 24 Sep 2003 14:52:00 +0200
- To: "'Jan Hidders'" <jan.hidders@ua.ac.be>, <www-ql@w3.org>
- Cc: <lehti@ipsi.fhg.de>
Here's my try about what the formal semantics (and IPSI-XQ as one of the implementations of XQuery that are closely aligned with the FS - at least for static reasoning). Guided by the normalization rules in the FS, IPSI-XQ rewrites/normalizes (<x><y id="1"/><y id="2"/></x>)/y as follows: http://www.w3.org/TR/query-semantics:distinct-doc-order(let $fs:sequence := (element x{ element y{ attribute id{ "1" } } , element y{ attribute id{ "2" } } } ) return let $fs:last := count($fs:sequence) return for $fs:dot at $fs:position in $fs:sequence return child::y) The interesting part happens in the expression element y{ attribute id{"1"}}, element y{ attribute id{"2"}} } This is a "core sequence" expression; see: http://www.w3.org/TR/xquery-semantics/#sec_constructing_sequences The dynamic semantics is given by: "The dynamic semantics of the sequence expression follows. Each expression in the sequence is evaluated and the resulting values are concatenated into one sequence." dynEnv |- Expr1 => Value1 dynEnv |- Expr2 => Value2 ------------------------------------------------------- dynEnv |- Expr1, Expr2 => Value1, Value2 applied to our sequence expression we thus have: dynEnv |- Expr1 => element y{ attribute id{"1"}} dynEnv |- Expr2 => element y{ attribute id{"2"}} ------------------------------------------------------------------------ ------------- dynEnv |- Expr1, Expr2 => element y{ attribute id{"1"}},element y{ attribute id{"2"}} The actual order (not the document order) appears to be well-defined (maybe too well;). Next, we construct the element: http://www.w3.org/TR/xquery-semantics/#doc-xquery-ElementConstructor Element construction is a rather complex beast, because a lot of special cases to deal with mixed content, typed vs. untyped values etc. needs to be taken into account, and a lot of implict processing for namespaces, validation etc. needs to take place. In your example, IPSI-XQ simplifies a bit, because the fs:item-sequence-to-node-sequence is an identity transformation in this case. Anyway, the input order to the constructed x-element is not changed, and by becoming the content of an element, the y-elements are now in document order within x. Hope this clarifies, Peter > -----Original Message----- > From: www-ql-request@w3.org [mailto:www-ql-request@w3.org] On > Behalf Of Jan Hidders > Sent: Mittwoch, 24. September 2003 13:04 > To: www-ql@w3.org > Subject: Re: creation order vs. document order > > > > Bas de Bakker wrote: > >>But now I'm still left with the following question. Is the > >>semantics of > >>the following expression well defined in the formal semantics? > >> > >> (<x><y id="1"/><y id="2"/></x>)/y > > > > I don't know about the formal semantics, > > Any information is welcome, although I really would like to know what > the formal semantics exactly say. Why else do they exist? > > > but will refer you again to > > section 3.2 of the data model: > > > > "The relative order of siblings is determined by their order in the > > XML representation. A node N1 occurs before a node N2 in document > > order if and only if the start of N1 occurs before the > start of N2 in > > the XML document." > > Since the fragment is constructed there is no original > representation we > can refer to. > > > And also: > > > > "Informally, document order is the order returned by an in-order, > > depth-first, left-to-right traversal of the data model." > > Shouldn't that be a *pre*order traversal? Also this cannot > tell us what > the relative order of the children is if we don't know that > order already. > > -- > Jan Hidders > > > .------------------------------------------------------------- > --------. > | Post-doctoral researcher e-mail: > jan.hidders@ua.ac.be | > | Dept. Math. & Computer Science tel: (+32) 3 218 > 08 73 | > | University of Antwerp fax: (+32) 3 218 > 07 77 | > | Middelheimlaan 1, BE-2020 Antwerpen, BELGIUM room: G > 3.21 | > > `------------------------------------------------------------- > --------' > >
Received on Wednesday, 24 September 2003 08:58:51 UTC