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 14557 - [QT3TS] Bugs in FOTS test-case: K2-SeqDocFunc-5
Summary: [QT3TS] Bugs in FOTS test-case: K2-SeqDocFunc-5
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3 & XPath 3 Test Suite (show other bugs)
Version: Working drafts
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Jim Melton
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
: 15371 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-10-25 08:58 UTC by O'Neil Delpratt
Modified: 2012-05-23 10:45 UTC (History)
2 users (show)

See Also:


Attachments

Description O'Neil Delpratt 2011-10-25 08:58:26 UTC
RE: test K2-SeqDocFunc-5 in fn-doc test-set
This test does not seem to serve its purpose because the URI used
(i.e. http://www.exaple.com//example.com/example.org/does/not/exist/doesNotExist/works-mod.xml) does exist in the form of a re-direct to another page.
Comment 1 Michael Kay 2011-10-25 14:00:47 UTC
Corrected URI:

http://www.example.com/example.com/example.org/does/not/exist/doesNotExist/works-mod.xml

As it happens, the test works by accident, because the document that IANA serves in response to this URL is not well-formed XML (although it claims to be XHTML, it has attributes with no surrounding quotes), so the XML parser barfs, giving the same error code as if the document were truly not there.

An associated problem is that the document that IANA serves contains a reference to the XHTML DTD on the W3C server, which creates operational difficulties (though there are other tests in the suite that do this quite legitimately, and implementations ought to be able to cope with it).

The trouble is, of course, that any HTTP URL is liable to be intercepted by some proxy that takes it upon itself to return a "document not found" page that might happen to be well-formed XML. So I would suggest using a URI with some non-existent protocol.
Comment 2 O'Neil Delpratt 2012-05-18 09:39:10 UTC
Assigning to Jim because this needs WG discussion.
Comment 3 O'Neil Delpratt 2012-05-18 09:49:46 UTC
*** Bug 15371 has been marked as a duplicate of this bug. ***
Comment 4 Michael Kay 2012-05-23 10:45:55 UTC
Discussed by the WG.

ACTION A-510-03 Michael Kay and O'Neil Delpratt to look at resolving bug 14557 by using another URI that meets the intent of the test (possibly a URI ending in .invalid, see RFC 2606, or possibly a file:// uri)

I have changed the test to use .invalid as suggested, and this seems to work for me.