3757 2006-09-21 03:45:54 +0000 [FS] technical: 2.3.1 ElementValue 2007-11-04 06:00:05 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Formal Semantics 1.0 Candidate Recommendation All All ASSIGNED P2 minor --- 1 jmdyck jmdyck public-qt-comments oldest_to_newest 11930 0 jmdyck 2006-09-21 03:45:54 +0000 2.3.1 / -- / para 4,5,6 "Element nodes have a type annotation and contain a complex value or a simple value. ... A simple value is a sequence of atomic values. A complex value is a sequence of attribute nodes followed by a sequence of element, text, comment, or processing-instruction nodes." First, this definition doesn't support the following example from 2.3.2: element weight of type xs:integer { attribute xsi:type of type xs:QName { "xs:integer" of type xs:QName }, 42 of type xs:integer } (An attribute node followed by an atomic value doesn't satisfy the definition for 'complex value' or 'simple value'.) More generally, what is the mapping between FS ElementValues and XDM ElementNodes? In particular, if an FS ElementValue V represents an XDM Element Node N, then what does V's inner Value represent, with respect to N? It seems that sometimes it represents the concatenation of N's 'attributes' and 'children' properties, and sometimes it represents the concatenation of N's 'attributes' and 'typed-value' properties. (The above example is an instance of the latter.) I think this is non-obvious enough that it should be spelled out. 12043 1 simeon 2006-09-26 14:59:05 +0000 Michael, That example is interesting. Here it corresponds to the fact that XML Schema allows complextype with simple content. I believe we are aligned with that I.e., you will find atomic values in the content iff the type has simple content. We may be better of sticking to XML Schema's terminology here, I don't think there is something wrong with the spec as is, but some clarifications could be added. Being that late in the process, specific suggested text would be greatly appreciated. Best, - Jerome 12056 2 simeon 2006-09-26 16:01:35 +0000 Michael, The XLST and XML Query Working Groups have considered that comment and decided to re-classify it as editorial. Further comments and suggestions on this thread would be greatly appreciated. Best, - Jerome On behalf of the XSLT and XML Query WGs 12214 3 jmdyck 2006-09-30 06:57:12 +0000 (In reply to comment #1) > > I don't think there is something wrong with the spec as is So you don't think the disagreement between definitions and example constitutes something wrong with the spec? > Being that late in the process, specific suggested text would be > greatly appreciated. Well, you could change "contain a complex value or a simple value" to "contain a sequence of attribute nodes followed by either a complex value or a simple value", and drop the attribute stuff from the defn of complex value. Note that "complex value" isn't used anywhere else, so there isn't a problem with changing its definition. That should take care of the definition/example disagreement. Not sure about the general mapping though. 12222 4 jmdyck 2006-10-01 02:13:50 +0000 (In reply to comment #0) > > In particular, if an FS ElementValue V represents an > XDM Element Node N, then what does V's inner Value represent, with > respect to N? It seems that sometimes it represents the concatenation > of N's 'attributes' and 'children' properties, and sometimes it > represents the concatenation of N's 'attributes' and 'typed-value' > properties. That fact that an V's inner Value doesn't represent N's 'children' and 'typed-value' properties at the same time is a serious problem, I think, because V might occur in a context that wants the property that isn't represented. For instance, consider the post-validation V referred to above: element weight of type xs:integer { attribute xsi:type of type xs:QName { "xs:integer" of type xs:QName }, 42 of type xs:integer } If you apply an axis step like child::node() to V, you'll get an empty sequence, because V does not contain any child NodeValues. But presumably it should yield a TextValue (i.e., text { "42" }), because the corresponding N does (still) have a Text Node in its 'children' property. 13090 5 jmdyck 2006-12-07 06:55:45 +0000 This problem is not resolved in the PR, which I believe is a serious shortcoming: if there isn't a well-defined correspondence between the XQuery/XPath Data Model and the objects that the FS manipulates, then there's a good chance that the semantics the FS defines are not the semantics of XQuery/XPath. 14207 6 jim.melton 2007-02-26 00:15:31 +0000 The complete fix for this bug does not appear in the Recommendation of 23 January 2007. It will be considered for a future publication (either an Errata document or some possible future version of the specification).