W3C home > Mailing lists > Public > public-qt-comments@w3.org > December 2012

[Bug 20416] New: Sequence Normalization Queries

From: <bugzilla@jessica.w3.org>
Date: Mon, 17 Dec 2012 17:48:36 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-20416-523@http.www.w3.org/Bugs/Public/>

            Bug ID: 20416
           Summary: Sequence Normalization Queries
    Classification: Unclassified
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Serialization 3.0
          Assignee: zongaro@ca.ibm.com
          Reporter: josh.spiegel@oracle.com
        QA Contact: public-qt-comments@w3.org

Section 2 says that when the item-separator serialization parameter is present,
sequence normalization is equivalent to constructing a document node as

  declare construction preserve;
  document {
    for tumbling window $w in $seq
      start when true()
      end $end when $end instance of node()
    return if (count($w) ge 2)
      then string-join($w[count($w)-1], $sep)
      else $w

fn:string-join accepts xs:string* so if the input sequence is (1, 2, 3) I would
expect this query to raise a sequence type matching error (sequence
normalization does not raise this error).  

Also, sequence normalization places the item-separator between each item in the
sequence.  I don't think the above windowing query achieves this.  For example,
assume the item-separator is "x".  If the input sequence is (text { 1 }, text {
2 }, text { 3 }), I think the result of the query is a document with the text
node "123" but the desired result is "1x2x3".  

I think the following query would better model sequence normalization when
item-separator is present:

  declare construction preserve; 
  document {
    for $item at $pos in $seq
    let $node := 
      if ($item instance of node()) then 
        text { $item }
      if ($pos eq 1) then
        ($sep, $node)  

The let clause converts atomic values in the sequence to text nodes.  The
purpose of this is to avoid the interleaving blanks that would be inserted by
the document constructor.  


A second minor problem is with the query used when the item-separator is

  declare construction preserve;
  document {
    for $s in $seq return
      if ($s instance of document-node())
      then $s/child::node()
      else $s

Document construction removes document nodes so manually removing the document
nodes is unnecessary.  I propose the following query instead:

  declare construction preserve;
  document { $seq }

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Monday, 17 December 2012 17:48:43 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:51 UTC