This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 3757 - [FS] technical: 2.3.1 ElementValue
Summary: [FS] technical: 2.3.1 ElementValue
Status: ASSIGNED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Formal Semantics 1.0 (show other bugs)
Version: Candidate Recommendation
Hardware: All All
: P2 minor
Target Milestone: ---
Assignee: Michael Dyck
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-21 03:45 UTC by Michael Dyck
Modified: 2007-11-04 06:00 UTC (History)
0 users

See Also:


Attachments

Description Michael Dyck 2006-09-21 03:45:54 UTC
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.
Comment 1 Jerome Simeon 2006-09-26 14:59:05 UTC
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
Comment 2 Jerome Simeon 2006-09-26 16:01:35 UTC
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
Comment 3 Michael Dyck 2006-09-30 06:57:12 UTC
(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.
Comment 4 Michael Dyck 2006-10-01 02:13:50 UTC
(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.
Comment 5 Michael Dyck 2006-12-07 06:55:45 UTC
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.
Comment 6 Jim Melton 2007-02-26 00:15:31 UTC
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).