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 5723 - CVS: K2-ComputeConAttr-54 Incorrect expected result
Summary: CVS: K2-ComputeConAttr-54 Incorrect expected result
Status: CLOSED INVALID
Alias: None
Product: XML Query Test Suite
Classification: Unclassified
Component: XML Query Test Suite (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Frans Englich
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-05-29 11:51 UTC by Tim Mills
Modified: 2008-06-25 11:51 UTC (History)
1 user (show)

See Also:


Attachments

Description Tim Mills 2008-05-29 11:51:06 UTC
I believe that K2-ComputeConAttr-54 might be wrong.

The only place that I can find a reference to the introduction of
a new namespace prefix is in XQuery 3.7.4 In-scope Namespaces of a Constructed Element.

The introduction of an implementation-dependent prefix will only occur when
the attribute is copied as a child of an element during element construction.

i.e. I expect the result of

<element>
{
  let $name := QName("http://example.com/", "attr"),
      $attr := attribute {$name} {()} return
    ( $attr, text { prefix-from-QName(node-name($attr)) } )
}
</element>

to be of the form

<element xmlns:generated-prefix="http://example.com/" 
         generated-prefix:attr=""/ >

and not

<element xmlns:generated-prefix="http://example.com/" 
         generated-prefix:attr="">generated-prefix</element>

Here's the XQTS query for reference.

(:*******************************************************:)
(: Test: K2-ComputeConAttr-54                            :)
(: Written by: Frans Englich                             :)
(: Date: 2007-11-22T11:31:21+01:00                       :)
(: Purpose: Ensure that a valid prefix has been constructed for a QName which th
e implementation is supposed to create a prefix for. :)
(:*******************************************************:)
string-length(xs:NCName(prefix-from-QName(node-name(attribute {QName("http://exa
mple.com/", "attr")} {()})))) > 0
Comment 1 Frans Englich 2008-06-24 14:30:05 UTC
This test case was in response to a queued errata change:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4443


Comment 2 Tim Mills 2008-06-24 15:04:20 UTC
I've queried the resolution to Bug 4443 in light of Bug 4463.

I came across this error while trying to write a test case to hit (from Bug 4463)

"(4) Section 3.7.3.2 (Computed Attribute Constructors)
Replace the paragraph following the first numbered list as follows:
A dynamic error [XQDY0044] is raised if the node-name of the constructed 
attribute node has any of the following properties:

(b) It has no namespace prefix and its local name is xmlns"

How can this be hit?  With 4443 implemented, the following:

attribute { fn:QName('xmlns', 'http://www.example.com/') } { 'foo' }

would create an attribute with an implementation-defined prefix, as if the user had written:

attribute { fn:QName('xmlns', 'http://www.example.com/') } { 'foo' }

Comment 3 Frans Englich 2008-06-24 15:19:14 UTC
Though to me it seems these test cases are conforming to the specs, when taking into account the erratas. Are you ok with reopening this report if/when 4443 gets reverted/changed?
Comment 4 Tim Mills 2008-06-24 15:35:53 UTC
Is this error listed in the errata yet?

If so, yes, otherwise I'd prefer to leave it open.

BTW, do you have any comments on what I've suggested regarding 4443?
Comment 5 Frans Englich 2008-06-25 11:37:55 UTC
What error? The error that a prefix is invented for an isolated attribute node as K2-ComputeConAttr-54 verifies? Yes, I believe the change to 3.7.3.2 as described in bug 4443 covers that.
Comment 6 Tim Mills 2008-06-25 11:51:16 UTC
Ah yes - it's XQ.E9.

OK.  I'll close this for the moment.