Nabble - w3.org - public-qt-comments

[Bug 6238] CVS: K2-NameTest-22

2009-12-17T04:23:10Z

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

--- Comment #8 from Tim Mills <tim@...> 2009-12-17 12:23:10 ---
I made a mistake in Comment #5.

The expected result of this test should be false, because the query is
equivalent to

empty(let $e := <a b ="content"><?b asd?><b/></a>
return $e/processing-instruction("b"))

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 8504] XQTS: CVS: K2-NameTest-21, K2-NameTest-23 invalid XQueryX

2009-12-16T06:37:24Z

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

--- Comment #5 from Michael Kay <mike@...> 2009-12-16 14:37:24 ---
I agree that it's not really reasonable to expect an XQueryX processor to
produce different error codes for different kinds of schema-invalid XQueryX
inputs.

To be honest, I've no idea why this one is a type error rather than a static
error anyway. It seems a curious decision.

Apart from the error code, it seems a reasonable test to include in the test
suite.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 8504] XQTS: CVS: K2-NameTest-21, K2-NameTest-23 invalid XQueryX

2009-12-16T06:21:34Z

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

--- Comment #4 from Tim Mills <tim@...> 2009-12-16 14:21:34 ---
>It tests that a processor can handle invalid input - which is surely a
>reasonable test?

Indeed this is reasonable, but these a
Then this test case should be marked as expecting a parse error in the XQueryX
case.

Our implementation raises a System.Xml.Schema.XmlSchemaValidationException
which we report directly - rather than reporing it as XPST0003 which would be
inappropriate since this is XQueryX we're dealing with.

(XPST0003: It is a static error if an expression is not a valid instance of the
grammar defined in A.1 EBNF)

Or do you suggest that we attempt to observe XPTY0004 by static type analysis
of a syntactically invalid XQueryX program?

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 8504] XQTS: CVS: K2-NameTest-21, K2-NameTest-23 invalid XQueryX

2009-12-16T05:36:42Z

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

--- Comment #3 from Michael Kay <mike@...> 2009-12-16 13:36:42 ---
>They're listed as expecting a type checking error at runtime, rather than failing to parse.

No, type errors can be reported either statically or dynamically.

>What benefit is there from including invalid XQueryX in the test suite?

It tests that a processor can handle invalid input - which is surely a
reasonable test?

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 8505] DTD of XQTSCatalog is invalid

2009-12-16T05:19:37Z

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

Oliver Hallam <oliver@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED

--- Comment #1 from Oliver Hallam <oliver@...> 2009-12-16 13:19:37 ---
I have changed the entry to:

<!ATTLIST input-query date CDATA #REQUIRED >

to match the other date attributes used in the test suite catalog, and have
marked the bug fixed.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 8505] New: DTD of XQTSCatalog is invalid

2009-12-16T05:16:50Z

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

Summary: DTD of XQTSCatalog is invalid
Product: XML Query Test Suite
Version: unspecified
Platform: PC
OS/Version: Windows NT
Status: NEW
Severity: normal
Priority: P2
Component: XML Query Test Suite
AssignedTo: andrew.eisenberg@...
ReportedBy: oliver@...
QAContact: public-qt-comments@...

The DTD of XQTSCatalog.xml contains the following entry:

<!ATTLIST input-query date ( 2006-02-09 | 2006-02-10 ) #REQUIRED >

an enumerated value must contain Name tokens, and so this is not a valid XML
1.0 DTD.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 8504] XQTS: CVS: K2-NameTest-21, K2-NameTest-23 invalid XQueryX

2009-12-16T05:10:03Z

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

--- Comment #2 from Tim Mills <tim@...> 2009-12-16 13:10:03 ---
They're listed as expecting a type checking error at runtime, rather than
failing to parse. What benefit is there from including invalid XQueryX in the
test suite?

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 8504] XQTS: CVS: K2-NameTest-21, K2-NameTest-23 invalid XQueryX

2009-12-16T04:44:24Z

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

Michael Kay <mike@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |mike@...

--- Comment #1 from Michael Kay <mike@...> 2009-12-16 12:44:24 ---
Both tests are documented as being error cases, so why is this a problem?

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 8269] [XQTS] CVS: last-23

2009-12-16T04:12:58Z

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

Tim Mills <tim@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|CLOSED |REOPENED
Resolution|FIXED |

--- Comment #3 from Tim Mills <tim@...> 2009-12-16 12:12:57 ---
I think the XQueryX version of this query needs to be regenerated.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 8504] New: XQTS: CVS: K2-NameTest-21, K2-NameTest-23 invalid XQueryX

2009-12-16T03:56:29Z

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

Summary: XQTS: CVS: K2-NameTest-21, K2-NameTest-23 invalid
XQueryX
Product: XML Query Test Suite
Version: unspecified
Platform: PC
OS/Version: Windows NT
Status: NEW
Severity: normal
Priority: P2
Component: XML Query Test Suite
AssignedTo: andrew.eisenberg@...
ReportedBy: tim@...
QAContact: public-qt-comments@...

These two tests are invalid with respect to the XQueryX schema, since neither
piTarget 123ncname (K2-NameTest-21) nor prefix:b (K2-NameTest-23) are valid
NCName values.

<xsd:element name="piTarget" type="xsd:NCName" minOccurs="0"/>

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 8503] New: grouping separators in format-integer

2009-12-15T16:16:33Z

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

Summary: grouping separators in format-integer
Product: XPath / XQuery / XSLT
Version: Working drafts
Platform: PC
OS/Version: Windows NT
Status: NEW
Severity: normal
Priority: P2
Component: Functions and Operators 1.1
AssignedTo: mike@...
ReportedBy: mike@...
QAContact: public-qt-comments@...

The new function format-integer attempts to extract part of the functionality
of xsl:number, for use within format-dateTime. At the same time it tries to
align where possible with format-number.

The way grouping separators are handled is inspired by format-number, but there
is an omission: to get output in the form 1,234 it is necessary to use a
picture such as 0,000 or 9,999; but this will result in the number 42 being
output as 0,042. We should therefore allow a "#" in the picture to denote a
character position that is omitted if it would otherwise be an insignificant
leading zero.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 8502] New: [XQuery 1.1] Organization of sections

2009-12-15T14:17:35Z

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

Summary: [XQuery 1.1] Organization of sections
Product: XPath / XQuery / XSLT
Version: Working drafts
Platform: PC
OS/Version: Windows NT
Status: NEW
Severity: normal
Priority: P2
Component: XQuery 1.1
AssignedTo: jonathan.robie@...
ReportedBy: mike@...
QAContact: public-qt-comments@...

The new XQuery 1.1 WD (published 15 Dec 2009) appears to have some editorial
problems in the organization of sections.

Section 3.1 is about Primary Expressions. Of the nine kinds of primary
expression, seven are described more fully in subsections 3.1.1 to 3.1.7 (the
other two, ordered and unordered expressions, are in section 3.9, which is not
a problem). But section 3.1.8 describes dynamic function invocations, which are
not primary expressions: placing them at this point in the spec, under the
heading "Primary Expressions" is therefore misleading.

Section 3.2.2 is headed "Predicates" and tries to describe both predicates as
used in Axis steps, and predicates as used in filter expressions (which are not
introduced until 3.3.2). But this isn't clear, because grammatically the two
constructs are now quite separate (and there are semantic differences too). The
inclusion of the production for FilterExpr in 3.2.2 is a red herring: this is
not what the section is about.

Section 3.3.2 is headed "Filter Expressions", which corresponds to the
metasymbol FilterExpr. Except that it doesn't any more: the definition of
"filter expression" is "A filter expression consists simply of a primary
expression followed by zero or more predicates.", which is narrower than the
metasymbol FilterExpr, which covers both filtering and dynamic function
invocation. The syntax of these two rather separate operations is now so
intertwined that it probably makes sense to cover the semantics in one place as
well.

In fact, the concept of "a primary expression followed by zero or more
predicates" really doesn't match anything in the grammar any more. I suggest
that we redefine it as being "an expression followed by a [single] predicate",
and change the prose accordingly.

A related problem is that 3.3.2 starts with two grammar productions (FilterExpr
and PredicateList) neither of which references the other. PredicateList doesn't
belong here.

If we're allowed to write the grammar to match the semantics (which is what I
have always done in my books), I would write it as

PostfixExpr := PrimaryExpr | FilterExpr | DynamicFunctionInvocation

FilterExpr := PostfixExpr '[' ExprSingle ']'

DynamicFunctionInvocation := PostfixExpr "(" (ExprSingle ("," ExprSingle)*)?
")"

Of course this is problematic because it has to be refactored to turn it into a
grammar that can be implemented without lookahead: but it's much clearer to the
human reader, and gives much better "hooks" into the prose describing the
semantics. I don't know if there is a solution to this problem: perhaps we
could present both grammars, assert that they are equivalent, and use the one
given here as the basis for describing the semantics. (Note that the current
metasymbol DynamicFunctionInvocation represents only the argument list,
although the semantic description in 3.1.8 treats it as if it is a complete
expression).

This approach would allow the structure

3.3.2 Postfix Expressions

3.3.2.1 Filter Expressions

3.3.2.2 Dynamic Function Invocation

There's always going to be a bit of messiness because predicates are used both
in axis steps and in filter expressions, with slightly different semantics, but
we can try harder to minimise the confusion.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 8500] Priority of validation errors

2009-12-15T08:47:42Z

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

Michael Kay <mike@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |mike@...

--- Comment #1 from Michael Kay <mike@...> 2009-12-15 16:47:42 ---
Seems reasonable to add the extra error code. Generally the presumption is in
favour of allowing alternative error codes if there's a plausible rationale for
them.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 8499] Expected results for numberulng1args-2 incorrect

2009-12-15T08:44:44Z

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

Michael Kay <mike@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |mike@...

--- Comment #1 from Michael Kay <mike@...> 2009-12-15 16:44:44 ---
I agree with the analysis.

Another possible result is FOAR0002 if the implementation does not support
18-digit integers.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 8500] New: Priority of validation errors

2009-12-15T08:18:04Z

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

Summary: Priority of validation errors
Product: XML Query Test Suite
Version: unspecified
Platform: PC
OS/Version: Windows NT
Status: NEW
Severity: normal
Priority: P2
Component: XML Query Test Suite
AssignedTo: andrew.eisenberg@...
ReportedBy: nick@...
QAContact: public-qt-comments@...

Looking at validateexpr-26:

validate { document { <a/>, <b/> } }

The error XQDY0061 (document node whose children do not consist of exactly one
element node ) is expected.

I think it is unclear in the spec whether XQDY0027 (root element information
item in the PSVI resulting from validation does not have the expected validity
property) might also permitted.

Are the validate rules expected to be followed in order, and errors thrown with
precedence from the order listed? If not, could the second error be added.

When streaming results being able to throw the XQDY0027 error is preferable as
it would be known before the XQDY0061 error.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 8499] New: Expected results for numberulng1args-2 incorrect

2009-12-15T08:15:14Z

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

Summary: Expected results for numberulng1args-2 incorrect
Product: XML Query Test Suite
Version: unspecified
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: XML Query Test Suite
AssignedTo: andrew.eisenberg@...
ReportedBy: kcormier@...
QAContact: public-qt-comments@...

Test case numberulng1args-2 has the following query:

(:*******************************************************:)
(:Test: numberulng1args-2 :)
(:Written By: Carmelo Montanez :)
(:Date: Thu Dec 16 10:48:17 GMT-05:00 2004 :)
(:Purpose: Evaluates The "number" function :)
(: with the arguments set as follows: :)
(:$arg = xs:unsignedLong(mid range) :)
(:*******************************************************:)

fn:number(xs:unsignedLong("130747108607674654"))

And it expects one of the following 2 results:

1.3074710860767466E17
1.307471086076747E17

The evaluation of this query should start with a cast from xs:string to
xs:unsignedLong, which does not change the value. fn:number casts to
xs:double, which is this case means casting the xs:unsignedLong to an
xs:string, and constructing the xs:double from that.

"A literal in the ·lexical space· representing a decimal number d maps to the
normalized value in the ·value space· of double that is closest to d; if d is
exactly halfway between two such values then the even value is chosen. This is
the best approximation of d ([Clinger, WD (1990)], [Gay, DM (1990)]), which is
more accurate than the mapping required by [IEEE 754-1985]. " [1]

This implies that the xs:double value will be 1.30747108607674656E17.

The final step is to cast the xs:double to xs:string for display. The
following rule applies:

"TV will be an xs:string in the lexical space of xs:double or xs:float that
when converted to an xs:double or xs:float under the rules of 17.1.1 Casting
from xs:string and xs:untypedAtomic produces a value that is equal to SV, or is
"NaN" if SV is NaN." [2]

In other words, we must be able to get back the original double value
1.30747108607674656E17 when we cast in the opposite direction. So, any of the
following results would be valid:

1.30747108607674648E17
1.30747108607674649E17
1.3074710860767465E17
1.30747108607674651E17
1.30747108607674652E17
1.30747108607674653E17
1.30747108607674654E17
1.30747108607674655E17
1.30747108607674656E17
1.30747108607674657E17
1.30747108607674658E17
1.30747108607674659E17
1.3074710860767466E17 *
1.30747108607674661E17
1.30747108607674662E17
1.30747108607674663E17
1.30747108607674664E17

One of these results (marked with an asterisk) is accepted by the test case,
but the other is not in this list and appears to be an error.

[1] XML Schema Part 2: Datatypes Second Edition, section 3.2.5:
http://www.w3.org/TR/xmlschema-2/#double

[2] XQuery 1.0 and XPath Functions and Operators, section 17.1.2:
http://www.w3.org/TR/xpath-functions/#casting-to-string

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 8498] New: orderBy62

2009-12-15T07:16:28Z

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

Summary: orderBy62
Product: XML Query Test Suite
Version: unspecified
Platform: PC
OS/Version: Windows NT
Status: NEW
Severity: normal
Priority: P2
Component: XML Query Test Suite
AssignedTo: andrew.eisenberg@...
ReportedBy: nick@...
QAContact: public-qt-comments@...

This query contains

for $x in xs:decimal($input-context1/DataValues/NegativeNumbers/orderData)

I believe what is intended is

for $x in $input-context1/DataValues/NegativeNumbers/orderData/xs:decimal(.)

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 8494] New: fn-idref-dtd-24 has incorrect node name

2009-12-15T05:17:23Z

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

Summary: fn-idref-dtd-24 has incorrect node name
Product: XML Query Test Suite
Version: unspecified
Platform: PC
OS/Version: Windows NT
Status: NEW
Severity: normal
Priority: P2
Component: XML Query Test Suite
AssignedTo: andrew.eisenberg@...
ReportedBy: nick@...
QAContact: public-qt-comments@...

fn-idref-dtd-24 cleary creates a node <result> to contain the result, but the
expected results have a node <results>

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 8408] Clarification on StringExcludes and Windows

2009-12-14T14:49:49Z

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

Michael Dyck <jmdyck@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID

--- Comment #3 from Michael Dyck <jmdyck@...> 2009-12-14 22:49:49 ---
At its meeting on December 7, the Task Force endorsed my responses above.
Consequently, I'm marking this issue Resolved-Invalid. If you agree, please
mark it Closed.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 7935] [F&O] normalize-unicode on codepoints that are not characters.

2009-12-11T15:48:41Z

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

--- Comment #4 from Michael Kay <mike@...> 2009-12-11 23:48:40 ---
At telcon 419 the following action was assigned:

ACTION A-419-03 Michael Kay (bug 7935) to propose a non-normative
clarification of normalize-unicode to explain the effect on unassigned
codepoints (viz, that the function is idempotent).

Proposed resolution (using the 2.0 baseline):

1. Update the reference to charmod to refer to the latest draft at
http://www.w3.org/TR/charmod-norm/ with a dated reference (because it is a
draft), and observe that this specification has not progressed beyond draft
status.

2. For normalization forms NFC, NFD, NFCK and NFDK refer directly to
http://www.unicode.org/reports/tr15/tr15-25.html rather than to CharMod. Retain
the reference to CharMod only for FULLY-NORMALIZED.

3. Add the following statement: It is implementation-defined which version of
Unicode (and therefore, of the normalization algorithms and their underlying
data) is supported by the implementation. See [TR15] for details of the
stability policy regarding changes to the normalization rules in future
versions of Unicode. If the input string contains codepoints that are
unassigned in the relevant version of Unicode, or for which no normalization
rules are defined, the fn:normalize-unicode function leaves such codepoints
unchanged. If the implementation supports the requested normalization form then
it MUST be able to handle every input string without raising an error.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 6848] [XSLT 2.1] xsl:copy select="$x"

2009-12-11T15:22:01Z

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

--- Comment #2 from Michael Kay <mike@...> 2009-12-11 23:22:01 ---
*** Bug 7110 has been marked as a duplicate of this bug. ***

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 7110] [XSLT 2.1] Add select attribute to xsl:copy

2009-12-11T15:22:01Z

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

Michael Kay <mike@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |DUPLICATE

--- Comment #1 from Michael Kay <mike@...> 2009-12-11 23:22:01 ---

*** This bug has been marked as a duplicate of bug 6848 ***

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 7092] [FO] Order of prefixes ambiguous for fn:in-scope-prefixes

2009-12-11T15:15:26Z

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

--- Comment #3 from Michael Kay <mike@...> 2009-12-11 23:15:25 ---
Discussion in meeting 419 led to this action:

ACTION A-419-01 Michael Kay to propose resolution to bug 7092. Define the
function in-scope-prefixes in terms of properties in the data model. Need to
check that XDM has the appropriate non-uniqueness constraint. And to handle
the inconsistency with the language documents.

What we identified was that the current description of the function was weak in
that it didn't tie up with anything in the data model. For example, if the data
model says that prefixes are unique, then the function description should not
need to repeat this.

The relevant accessor in the data model is dm:namespace-bindings, defined thus:

http://www.w3.org/TR/xpath-datamodel/#dm-namespace-bindings

"The dm:namespace-bindings accessor returns the dynamic, in-scope namespaces
associated with a node as a set of prefix/URI pairs, using an
implementation-dependent representation."

Curiously, the function prototype gives the result type as xs:string*. How this
sequence of strings is used to represent a set of pairs of strings is anyone's
guess - but I sympathise with the author's problem.

Describing it as a "set of prefix/URI pairs" does not in itself say that there
cannot be two pairs with the same prefix (mapped to different URIs).

Section H.7 repeats that in the case of element nodes, the accessor returns a
set of pairs, but curiously for other kinds of node it returns not an empty set
but an empty sequence. (But F+O invokes the accessor only for element nodes).

The accessor in the case of element nodes is defined in terms of the
"namespaces" property of the element node, but the spec actually says very
little about what that property is. Sometimes it appears to be a set of
namespace nodes, sometimes it appears to be a set of prefix/URI pairs. Perhaps
the ambiguity is deliberate?

Consistency constraint 13 in the description of element nodes (6.2.1) gives up
talking about the namespaces property entirely, and instead talks about
namespace bindings and namespace nodes.

I can't find any constraint in the data model that the namespaces of an element
must all have distinct prefixes. (Equally, I can't find a constraint that the
attributes have distinct QNames.)

Generally, I'm obliged to conclude that for 2.0, the data model does not
provide a very solid foundation for defining this function, and we are
therefore better off patching it up with sticky tape. Perhaps we can do better
in 2.1, but it will need a thorough rewrite of the way namespaces are described
in XDM, taking into account the above input.

So my proposal for a 2.0 erratum, as a minimum fix for this bug report, is to
change the specification of fn:in-scope-prefixes as follows:

Replace the current text:

<old>
Summary: Returns the prefixes of the in-scope namespaces for $element. For
namespaces that have a prefix, it returns the prefix as an xs:NCName. For the
default namespace, which has no prefix, it returns the zero-length string.
</old>

by

<new>
Summary: Returns the prefixes of the in-scope namespaces for $element.

The function returns a set of strings, corresponding to the prefixes of the
in-scope namespace bindings for $element, as delivered by the
dm:namespace-bindings accessor [DM].

For a namespace binding that has a prefix, it returns the prefix as an
xs:NCName. For the default namespace, which has no prefix, it returns the
zero-length string.

The result is represented as a sequence of strings containing no duplicates, in
implementation-dependent order.

Note: the result will always include the string "xml", since a binding for this
prefix is always in scope. It will include the string "" (representing the
default namespace) only if there is a default (non-empty) namespace in scope
for $element.
</new>

with corresponding changes to F+O 1.1 until such time as a more solid
description is in place in XDM.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 8327] declaration is result for last-23

2009-12-11T14:31:48Z

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

Michael Kay <mike@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED

--- Comment #1 from Michael Kay <mike@...> 2009-12-11 22:31:48 ---
Fixed as suggested

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 8460] missing module module-pub-priv

2009-12-11T13:45:29Z

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

Michael Kay <mike@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED

--- Comment #1 from Michael Kay <mike@...> 2009-12-11 21:45:29 ---
Now committed.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 8480] New: XQTS: CVS: comp-attr-bad-name-1 vs. K2-ComputeConAttr-38

2009-12-11T08:09:25Z

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

Summary: XQTS: CVS: comp-attr-bad-name-1 vs. K2-ComputeConAttr-38
Product: XML Query Test Suite
Version: unspecified
Platform: PC
OS/Version: Windows NT
Status: NEW
Severity: normal
Priority: P2
Component: XML Query Test Suite
AssignedTo: andrew.eisenberg@...
ReportedBy: tim@...
QAContact: public-qt-comments@...

Recently added test 'comp-attr-bad-name-1'

(: 3.7.3.2 Computed Attribute Constructor per XQ.E19
XQDY0044 if namespace prefix is 'xmlns'
Mary Holstege
:)

(: insert-start :)
(: insert-end :)

<result>{attribute {"xmlns:error"} {}}</result>

and older test K2-ComputeConAttr-38

(:*******************************************************:)
(: Test: K2-ComputeConAttr-38 :)
(: Written by: Frans Englich :)
(: Date: 2007-11-22T11:31:21+01:00 :)
(: Purpose: This query yields XPST0081 because the prefix 'xmlns' is unbound(
#2). :)
(:*******************************************************:)
attribute {"xmlns:localName"} {"content"}

essentially test the same thing but expect different errors.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 8477] New: [XSLT 2.0] lang attribute of xsl:sort and xsl:number

2009-12-11T05:33:04Z

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

Summary: [XSLT 2.0] lang attribute of xsl:sort and xsl:number
Product: XPath / XQuery / XSLT
Version: Recommendation
Platform: PC
OS/Version: Windows NT
Status: NEW
Severity: normal
Priority: P2
Component: XSLT 2.0
AssignedTo: mike@...
ReportedBy: mike@...
QAContact: public-qt-comments@...

For both xsl:sort and xsl:number we make two statements about the lang
attribute:

(a) we give the format in the syntax template as

lang? = { nmtoken }

(b) we say that the range of permitted values is the same as for xml:lang, with
a reference to the XML specification

These are inconsistent: the xml:lang attribute allows a zero-length string,
whereas nmtoken does not.

Also, the reference to xml:lang could be taken as implying that the language
must be present in the various lists of registered languages, rather than
merely conforming to the correct syntax.

I would suggest that

(i) we change the syntax template to

lang? = { xs:language? }

(ii) rather than referring to xml:lang, we say that the value must either be a
zero-length string or a string in the value space of xs:language. This makes it
clear that the constraint is purely syntactic.

(iii) we specify that the zero length string has the same effect as omitting
the lang attribute.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 8407] [XQFTTS] MildNot test cases

2009-12-09T12:35:56Z

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

Pat Case <pcase@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |pcase@...
Status|NEW |RESOLVED
Resolution| |FIXED

--- Comment #1 from Pat Case <pcase@...> 2009-12-09 20:35:56 ---
Hi Peter,

Again, thanks for your help.

Again, please mark the bug closed or let us know that you remain unsatisfied.

--Responses follow inline:

- FTMildNot-q2/FTMildNot-unconstrained-q2:
$input-context/books/book[para contains text "usability studies" not in
"usability"]/title

(against ftbookexample)

The expected result is "Ninja Coder", but I think that the correct result
should be empty. "usability studies" is indeed found in the "ninja coder" book,
but one of the matches of "usability" is found inside "usability studies",
therefore fulfilling the FTMildNot requirement for removing this match from the
result.
(I reported this problem in a private mail to Jim Melton before, the answer
might have been lost)

--No change. We believe your evaluation is correct for "usability" not in
"usability studies", but not for this example "usability studies" not in
"usability". In the latter, "usability studies" must be a part of the match
for "usabiity" to exclude the match. That can never be, so Ninja Coder is
returned. The MildNot only excludes matches where the first operand is a subset
of the second.

- FTMildNot-bad3: The intent of the query seems to generate a StringExclude by
using a FTTimes, triggering an error in FTMildNot.

If I understand the semantics of FTTimes and FTUnaryNot correctly, in this
specific case no StringExclude will be generated:
- The FTTimes is applied on the Matches for "ninja", within the search context
of $input-context/books/book/para there is only a single Match with a single
StringInclude (in the "para" element in the "Ninja Coder" book)

- According to the FTTimes semantics (4.2.6.10 FTTimes),
fts:FormRange((M(S("Ninja"))), 1, 1, $allMatches/@stokenNum) is invoked,

- In FormRange, fts:FormCombinationsAtLeast() is invoked for $times values of 1
and 2, the result of the latter is then negated using FTUnaryNot

- The invocation (denoted as $am1) with $times eq 1 yields M(S("Ninja"))
- The invocation (denoted as $am2) with $times eq 2 yields (), since the number
of elements in the match sequence is smaller than $times (and the for clause in
FormCombinationsAtLeast will therefore not produce anything)

- FTUnaryNot is applied on $am2 (with the an () value), resulting in an
AllMatch containing a match without any StringExcludes or StringIncludes (see
UnaryNotHelper: if (fn:empty($matches)) then <fts:match/>

--Agreed. Thinking the test case was supposed to illustrate this statement in
section 3.5.3 [Mild-Not Selection]:
Operands of a mild-not selection may not contain a full-text
selection that evaluates to an AllMatches that contains a
StringExclude. Such full-text selections are not-selection and
FTWords with a cardinality constraint using 'at most', 'from ... to',
and 'exactly' occurrences ranges. If such an expression is
encountered, an error [err:FTDY0017] is raised.
--We replaced the test suite query with:
(: FTMildNot-bad3: mild not with bad argument :)

(: insert-start :)
declare variable $input-context external;
(: insert-end :)

$input-context/books/book[para contains text "blues" occurs exactly 1 times not
in "oxford blues""]/title

Pat Case, Library of Congress, for the Full Text Task Force

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 8403] Several issues on use cases, including consistency with XQFTTS

2009-12-09T11:54:13Z

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

Pat Case <pcase@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED

--- Comment #1 from Pat Case <pcase@...> 2009-12-09 19:54:12 ---
Peter,

Thank you for reporting these errors in the test suite. We very much appreciate
your assistance in getting the test suite right.

I report below the action we took on each item. Please review them and if they
appear to you to be satisfactory, please mark this bug closed. If not, please
let us know what continues to be problematic.

1) 14.2.1: Test Suite expects empty results, document non-empty.
--We corrected the XQuery solution in the Use Cases to:
for $book in doc("http://bstore1.example.com/full-text.xml")
/books/book
let $p := $book//p[. contains text "testing" ftand "guidance" ftor
"correct" distance at most 60 words without content *]
return $book
--We replaced the test suite result with the use cases result.

2) 14.2.2: Queries in document specify to include all chapters, not just the
ones containing the search terms. The expected result in both the UC document
and the suite list only the chapter containing the terms, not all.
ignore-queries-q2 (XQuery solution in suite) is different from UC document (and
the XPath solution), lists all books, not just the one with the relevant
chapter.
--We corrected the XQuery solution in the Use Cases to:
for $book in doc("http://bstore1.example.com/full-text.xml")
/books/book
let $chap := $book//chapter[
. contains text "users can be tested at any
computer workstation or in a lab" without content
.//footnote]
return ($book/metadata/title, $chap)
--We replaced the test suite result with the use cases result.

3) 14.2.3: The same discrepancy between XQuery and XPath solution as in 2)
shows up in the UC document and the test suite, so all titles are listed for
the XQuery case (and just the relevant chapter), while the matching books with
all chapters are in the XPath case
--We replaced the XQuery and XPath solutions in both documents. For bevity, I
provide only the XQuery solution from the use cases:
for $chapter in doc("http://bstore1.example.com/full-text.xml")
/books/book//chapter
where $chapter contains text "at any computer
workstation or in a lab" without content
.//footnote[. contains text "workstation." using wildcards]
return ($chapter/ancestor::book/metadata/title, $chapter)
--We replaced the test suite result with the use cases result.

4) 14.2.4: Same error as in 2) in 3) present in the test suite, but corrected
in the UC document
--We replaced the XQuery and XPath solutions in both documents. For bevity, I
provide only the XQuery solution from the use cases:
for $chapter in doc("http://bstore1.example.com/full-text.xml")
/books/book//chapter
where $chapter contains text "workstation" ftand "lab"
distance at most 6 words without content .//footnote[.
contains text "workstation." using wildcards]
return ($chapter/ancestor::book/metadata/title, $chapter/(p|p/footnote))
--We replaced the test suite result with the use cases result.

- In 15.2.4 Q4, two issues are present
1) the ignore part of the second FTContains uses .//footnote, even though no
expression before has not set a context item (unless FTContains sets a context
item, which seems to contradict the description and a number of other test
cases).
2) $au contains text fnot should not become true for book number=2, since $au
is () there, and the description of the FTContains semantics (4.3 in FT CR)
seems to imply that an empty search context always yields false. Several tests
in the test suite support this
--We replaced the XQuery solutions in both documents. For bevity, I provide
only the XQuery solution from the use cases:
for $book in doc("http://bstore1.example.com/full-text.xml")
/books/book
let $au := $book/metadata/author
let $co := $book/content
where $au contains text ftnot ("montana" ftand "marigold")
and $co contains text "correct" ftor "comment"
using stemming ftor "guidance" ftor "assistance"
ftor "help" ftand "usability test.*" using wildcards
window 80 words without content $co//footnote
return <book number="{$book/@number}">
{$book/metadata/title, $co}
</book>
--We changed the results in the use cases to No Results Found following our
convention in that document and in the test suite to an empty document.

- In 16.2.9 Q9 (xquery-xpath-composability-queries-results-q9a/9b), the
keywords "succesfully", "completing" and "tasks" are queried using stemming,
and within an unordered window of 4*#chapters in a book. The MXQuery
implementation uses a Porter-based stemmer and turns these keywords into the
stems "success", "complet" and "task". As a result, the following paragraph
also matches this query:

<p>Users are asked to complete tasks which
measure the success of the information
architecture and navigational elements of the
site.</p>

(less than 12 words, unordered)

which in turn means that the book with shortTitle "Improving Web Site
Usability" is part of the generated result. If there is no error in my
reasoning (and implementation), I'd suggest fixing the use case either by
+ requesting "ordered" or
+ not using stemming or
+ adding the second book to the result
--No change. We recommend you use the stemming dictionary provided for testing.
If you prefer to use a different stemmer and get different results, you may
explain why, but we encourage you to follow the instructions in the test suite
quoted here:
When the catalog entry for a query references a stemming dictionary,
the implementation is expected to provide stemming equivalent to the
rules given in the stemming dictionary.

- In 17.2.6 Q6 the boolean output of a FTContains is again queried using a
FTContains, and part of the result:

let $booktext := $book/content contains text ...
let score $s := $booktext contains text ...
return ($book/metadata/title, $booktext)

Probably the correct query is

let $booktext := $book/content [. contains text ... ]
let score $s := $booktext contains text ...
return ($book/metadata/title, $booktext)
--We used your write and replaced the XQuery solutions in both documents. For
bevity, I provide only the XQuery solution from the use cases:
for $book in doc("http://bstore1.example.com/full-text.xml")
/books/book
let $booktext := $book/content [. contains text ("conduct"
ftand "usability" ftand "tests" distance at most
10 words) using stemming]
let score $s := $booktext contains text
(("measuring" ftand "success" distance
at most 4 words) weight {0.8}) using stemming
order by $s
return ($book/metadata/title, $booktext)

Again, thanks for your assistance!!!!

Pat Case, Library of Congress, for the Full Text Task Force

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 7247] xquery full text grammar ambiguity?

2009-12-08T12:31:37Z

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

Nikolay Ognyanov <nikolay.ognyanov@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED

--- Comment #8 from Nikolay Ognyanov <nikolay.ognyanov@...> 2009-12-08 20:31:37 ---
My experiments with parser generation confirm that this solution works. I agree
that the problem is fixed.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 5696] [XQuery 1.1] Feature request to aid static typing

2009-12-08T10:09:45Z

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

Michael Dyck <jmdyck@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED

--- Comment #4 from Michael Dyck <jmdyck@...> 2009-12-08 18:09:44 ---
At today's Working Group meeting, Nick Jones (the original poster) reviewed
this bug, and said that try/catch allowed an adequate solution to the problem.
Therefore, I am marking this bug Resolved-Fixed, and also Closed.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 5308] [FO 1.1] Timezone Z in format-dateTime()

2009-12-08T09:02:40Z

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

--- Comment #6 from Michael Kay <mike@...> 2009-12-08 17:02:39 ---
At its meeting on 8 December 2009 the WG indicated support in principle for the
ideas in comment #5 and gave the author an action to develop this into a
concrete proposal. Note spelling Olsen -> Olson.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 6951] [XSLT] Conflicting requirements for type annotations from XSLT validation='lax' and XDM

2009-12-08T08:42:10Z

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

--- Comment #5 from Michael Kay <mike@...> 2009-12-08 16:42:09 ---
On 8 Dec 2009 the joint WGs agreed to make this change, both to the 1.0 and 1.1
XDM specifications.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 7095] modules-none: different URI in test and catalog

2009-12-08T08:35:17Z

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

Mary Holstege <holstege@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED

--- Comment #1 from Mary Holstege <holstege@...> 2009-12-08 16:35:17 ---
Looks like this is fixed.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 8460] New: missing module module-pub-priv

2009-12-08T07:36:38Z

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

Summary: missing module module-pub-priv
Product: XML Query Test Suite
Version: unspecified
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: XML Query Test Suite
AssignedTo: mike@...
ReportedBy: andrew.eisenberg@...
QAContact: public-qt-comments@...

Module module-pub-priv is defined in the sources portion of the catalog. The
file that it refers to, module-pub-priv.xq, is missing.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.