Re: DOM Level 3 LS test results

>>I've fixed the thirdElt problem and stripped test2.xml of whitespace and 
>>the XML declaration.
>>    
>>
>
>I'm still seeing whitespace - a newline at the end. Probably CVS has done
>this. (Would require a checkin-as-binary to fix?)
>  
>
Does the terminal whitespace cause the test to fail?

>>loading a file from the file system, even if its extension is .pdf should
>>not be sufficient.
>>    
>>
>
>Well... it might be, on a filesystem that stores media type info in metadata
>(Mac OS does doesn't it?). Whether the extension could be said to constitute
>such metadata on its own is another issue. Anyway, I agree it's probably not
>something TS should be relying on.
>  
>
I think I know a way that this test could be done on Java without having 
an external resource.  Pretty complicated, so it isn't going to be on 
the top of my list until I just need a challenge.  Could add a 
contentType attribute to getResourceURI.  If that is specified, it would 
create a "x-jar:" URL that would also encode the expected content type.  
Would have to register a protocol handler for "x-jar:" that would 
extract the content type and delegate to the regular jar: protocol 
handler.  For ECMAScript, the content type would be ignored and you 
would have to depend on the HTTP server delivering the test files to 
provide an appropriate content type.

>  
>
>>none of my available implementations can get far enough to fail due to
>>its absense.
>>    
>>
>
>SystemId2 works fine for me.
>
>  
>
Cool.  Hopefully, it didn't overwrite your home page. 

The spec explicitly addresses what should be attempted if the URL is 
http.  SystemId1 attempts to write to a file: URL.  I think it 
represents a reasonable expectation, but might overreach what is 
actually in the spec.  Both of these tests can fail for external 
causes.  If you shut down the local http server or change the 
permissions, a conformant implementation can fail SystemId2.  If don't 
have priviledges to write a temporary file, SystemId1 can fail.

>>LSInput.encoding is set to UTF-8 but document.inputEncoding is 
>>expected to be 'UTF-16'.
>>    
>>
>
>Hmm. Not sure about this, should a string be considered to have an encoding
>at all? A bit tricky for Python because although DOMString is 16-bit, it is
>bound to native string types, which could equally be 8-bit (in which case
>the encoding would be 'us-ascii'), or 32-bit (in which case it is 'utf-32').
>
>(In practical terms, setting document.inputEncoding when creating a document
>from a string would mean that it would default to being saved as UTF-16
>instead of the usual UTF-8. Not sure this is desirable, but again the spec
>should really clarify.)
>  
>
Should raise this to the working group.

>>LSSerializerFilter in the candidate recommendation extends NodeFilter in 
>>traversal.  L2 Traversal's NodeFilter uses n as the parameter name.
>>    
>>
>
>Ah. You're right: only LSSerializerFilter inherits from NodeFilter, LSParser
>doesn't, which is why the argument names can be different. Oops.
>
>  
>

I'd would like it if the names could be synchronized that is renaming 
nodeArg to n,

>  
>
>>>LSParserConfig8, LSSerializer8: actually tests for xml-declaration instead 
>>>of well-formed
>>>      
>>>
>>Comment changed.
>>    
>>
>
>OK, if these really are meaning to test for xml-declaration, the canSetFalse
>tests should be assertTrues instead of false (which would make sense for
>well-formed).
>  
>
I believe these were intended as tests on 'well-formed' and 
'xml-declaration' was just a cut and paste error.  I've comitted changes 
as a continuation of bug 441.

Received on Friday, 19 December 2003 11:17:40 UTC