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 5394 - CVS: fn-doc-32
Summary: CVS: fn-doc-32
Status: CLOSED FIXED
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-01-18 13:43 UTC by Tim Mills
Modified: 2008-04-28 13:34 UTC (History)
0 users

See Also:


Attachments

Description Tim Mills 2008-01-18 13:43:18 UTC
The expected result of fn-doc-32 should be compared as a fragment, not as XML.

(: Name: fn-doc-32 :)
(: Description: Open an XML document that has ISO-8859-1 as encoding. :)

(: insert-start :)
declare variable $input-context as xs:anyURI? external;
(: insert-end :)

string(fn:doc($input-context)),
string(exactly-one(fn:doc($input-context)/*))
Comment 1 Frans Englich 2008-01-21 13:29:48 UTC
This should be fixed in CVS, do feel free to verify.


Frans
Comment 2 Tim Mills 2008-01-21 17:39:49 UTC
The expected result is:

Everyday Italian Giada De Laurentiis Everyday Italian Giada De Laurentiis

but we get


  Everyday Italian
  Giada De Laurentiis
 [[ CR here for readabilyt ]]

  Everyday Italian
  Giada De Laurentiis

Comment 3 Frans Englich 2008-02-29 16:00:36 UTC
I've updated the baseline, but I'm a bit uncertain on if I got it right(at this point). So feel free to verify and close if suitable.
Comment 4 Tim Mills 2008-03-03 16:02:05 UTC
The input file is:

0000000   <   ?   x   m   l       v   e   r   s   i   o   n   =   "   1
0000020   .   0   "       e   n   c   o   d   i   n   g   =   "   I   S
0000040   O   -   8   8   5   9   -   1   "   ?   >  \r  \r  \n   <   b
0000060   o   o   k   s   t   o   r   e   >  \r  \r  \n           <   t
0000100   i   t   l   e       l   a   n   g   =   "   e   n   "   >   E
0000120   v   e   r   y   d   a   y       I   t   a   l   i   a   n   <
0000140   /   t   i   t   l   e   >  \r  \r  \n           <   a   u   t
0000160   h   o   r   >   G   i   a   d   a       D   e       L   a   u
0000200   r   e   n   t   i   i   s   <   /   a   u   t   h   o   r   >
0000220  \r  \r  \n   <   /   b   o   o   k   s   t   o   r   e   >  \r
0000240  \r  \n

The character sequence \r\r\n should normalize to \n\n, so the expected result should be:

"<doc>\n\n  Everyday Italian\n\n  Giada De Laurentiis\n\n \n\n  Everyday Italian\n\n  Giada De Laurentiis\n\n</doc>" 

rather than 

"<doc>\n  Everyday Italian\n  Giada De Laurentiis\n \n  Everyday Italian\n  Giada De Laurentiis\n</doc>"
Comment 5 Frans Englich 2008-04-28 12:04:40 UTC
It seems this has been fixed now. Or at least, my suite driver passes the test on both Windows XP and Linux.

Here's what was the problem. The actual baseline file was correct; it was CVS that modified the EOLs when checking the files out on Windows. I added a new file with the binary keyword set(setting it on the existing one didn't work out).

Feel free to verify.


Comment 6 Tim Mills 2008-04-28 13:34:14 UTC
Thanks.