zorba-coders team mailing list archive

[Sorin Marian Nasoi <sorin.marian.nasoi@xxxxxxxxx>]

> 1. Unless I'm missing something, we don't want the function util:replace-
> entity-references(). The result of calling fn:serialize() should be exactly
> the XML we wish to canonicalize; if it contains < and > then there's a
> problem.
It's because in FOTS it's stated that we should use XML serialization in 'assert-xml' implementation.
Please see 
http://dev.w3.org/cvsweb/2011/QT3-test-suite/catalog-schema.xsd?rev=1.29;content-type=text%2Fplain
[...]
Asserts the result of the query by providing a serialization of the expression result using the default serialization parameters method="xml" indent="no" omit-xml-declaration="yes"
[...]


> 2. I also don't like the $actualResult1 / $actualResult2 disparity. Surely
> there is only one correct way to serialize a sequence of items according to
> FOTS? I think maybe util:serialize-result() should return xs:string rather
> than xs:string*, and it should handle either directly concatenating nodes or
> concatenating simple items with space delimiters if that is necessary.
It's a bug/inconsistency in FOTS. They do not state explicitly how the sequences of elements should be treated. In order to fix these cases I know that Michael Kay tried to replace all expected results presented as sequences with single elements.
Assuming we have a test-case returning 3 items: '1' and '2' as xs:string and element <a/>, test creators will enter expected result as:

1) <assert-xml><![CDATA[1 2 <a/>]]</assert-xml>

2) <assert-xml><![CDATA[12<a/>]]</assert-xml>

3) <assert-xml><![CDATA[1 2<a/>]]</assert-xml>
see http://dev.w3.org/cvsweb/2011/QT3-test-suite/fn/in-scope-prefixes.xml?rev=1.3;content-type=text%2Fplain
and look for "K2-InScopePrefixesFunc-11"

The case you mention covers situations 1) and 2) and I will report the situation described at 3) as a bug to W3C.



> 3. Why did you add the new "order by" clause in reporting.xq ? If that's only
> for W3C reporting then I don't really care, but I'm curious.
The ordering has nothing to do with W3C reporting.
It only concerns 'generate-expected-failures' mode.


> 4. Finally, I'm concerned that this caused new EXPECTED_FOTS_FAILURE()s to be
> added. Why is that? Were we generated false positives before, or is there a
> problem in the canonicalization?
There differences you see come from the lack of ordering in the EXPECTED_FOTS_FAILURE.
-- 
https://code.launchpad.net/~zorba-coders/zorba/fix_bug_1086398/+merge/152788
Your team Zorba Coders is subscribed to branch lp:zorba.