- 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