This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
ForExprType036 ForExprType055 ForExprType058 ForExprType059 ForExprType060 default_namespace-011 Are all specified as using XML comparison, but need Fragment as they are not well formed (multiple top level elements, or no top level element in the last case)
ForExprType059 and ForExprType060 consist of a single, top-level processing instruction, so I beleive the XML comparator is more appropriate. default_namespace-011 has a textual result. I have updated the others to use the fragment verifier.
> ForExprType059 and ForExprType060 consist of a single, top-level processing > instruction, so I beleive the XML comparator is more appropriate. But a single PI is not a well formed XML document, and my test harness not unreasonably throws a fatal error when trying to parse the expected result as XML in these cases as the expected result is not well formed. The XML REC says: [1] document ::= prolog element Misc* - Char* RestrictedChar Char* Matching the document production implies that: 1. It contains one or more elements. > default_namespace-011 has a textual result. Yes, although It's marked as XML comparison. Do you mean you've changed it to Text? (That's OK although see bug #2402 on text comparison)
Okie - that makes sense. I have updated the tests to use the text comparator.
(In reply to comment #3) > Okie - that makes sense. I have updated the tests to use the text comparator. Why Text not Fragment? Currrently I'd fail this with Text comparison as I understood Text to imply the text serialisation. If the result tree is serialised as text you get "" as the string value of a document node that just has a PI child is a zero length string. If Text comparison implies comparing the expected result file as text with an XML serialisation (which would then show the PI in this case) several of the text comarison expected result files need changing back to use XML syntax. (I'm Confused:-) see bug #2402
No - 'text' does not imply text serialization. 'Text' is the comparator in this case and is simply an indication of how best to comapre the results of your query with those supplied by the test suite. The comparator does not make any attempt to change how the results of the query itself is serialized, that is up to the test harness. Thus, any 'XML' or 'Fragment' results could be compared using 'text', but certain features of these types of results (e.g. undefined attribute order, insignificant whitespace, etc.) could cause false failres if we simply used textual comparisson. The test suite does not enfore any particular form of serialization of the results - mainly becuase there is no, single, fixed serialization defined for the entire XQuery data model. This means that certain features of the language (e.g. the document-node, typing information, etc.) which do not have explicit, user-visible serializations can not be explicitly tested.