- From: Curt Arnold <carnold@houston.rr.com>
- Date: Tue, 30 Dec 2003 06:30:00 -0600
- To: www-dom-ts@w3.org
> >Spec issues: >------------ > >1. feature: "charset-overrides-xml-encoding" > > Proposal: strike this from the spec. We have currently no > intentions to implement this. > >2. feature: "well-formed" > > IBM requested to remove this issue. See: > http://lists.w3.org/Archives/Member/w3c-dom-ig/2003Dec/0019.html > We are indifferent when it comes to this feature. There are no >requests from > customers to implement it, on the other hand we don't see any issues > with the implementation of it. It is currently not implemented > > >3. We don't support the + in feature names. > example: domImpl.hasFeature("+lS", "3.0"); > > Since we don't do a full core implementation we would like to strip > this dependency within LS. > > HasFeature04 and HasFeature05 will be modified to only be applicable when hasFeature("Core", "3.0") is true. GetFeature02 already had that precondition. >4. An empty LSOutput reports a no-output-specified at the Error Handler > see: >http://www.w3.org/TR/2003/CR-DOM-Level-3-LS-20031107/load-save.html#LS-L >SSerializer > an empty LSInput reports none. > Proposal: add no-input-specified to LSInput in this case. > See also test: DOMBuilderTest6 > > That was discussed in the last conference call. > > >Issues with tests: >----------------- > > >1. DOMBuilderTest5 > > Issue : throws exception in stead of using the error handler > Resolution: We will change our implementation in such a way that > our default error handler will throw the exception > >2. DOMBuilderTest6 > > Issue : throws exception in stead of an ingore of an empty >LSInput > Resolution : We will change our implementation in such a way that our > > default error handler will throw the exception. The test > > will have to set a null error handler to support this ! > > > >3. DOMBuilderTest8 > > Issue : throws FileNotFoundException in stead of reporting to > the Error Handler > Resolution : We will change our implementation in such a way that our > > default error handler will throw the exception. The test > > will have to set a null error handler to support this ! > > > Andrew Clover (http://lists.w3.org/Archives/Public/www-dom/2003OctDec/0077.html) also implemented his Python L&S where parse failures threw IO and similar exceptions. The spec doesn't give a huge guideance on the reporting of error conditions, the current scheme of swallowing exceptions and returning null in the Java implementations is compelled by method signature in the Java binding prohibiting throwing checked exceptions other than DOMException. Instead of immediately conforming to the other Java implementations, I'd hold off until we address this issue. Could you describe the exceptions you are throwing? Could you formulate a proposal for changes to L&S where parse failures are signalled by exception when not suppressed by the error handlers? I think it would probably involve deriving DOMError off "Exception" and ideally having a innerException member that could be a platform exception like an IOException. > >4. DOMImplementationLSTest1 > > Issue : This is an Async test, it should be optional. > Resolution : Curt will fix the test see: > >http://lists.w3.org/Archives/Public/www-dom-ts/2003Dec/0031.html > > > > At the previous change, this test should only be run if "LS-Async" is true. If you are still failing it, are you indicating that you support Async parsing? >5. DOMInputSourceTest3, DOMInputSourceTest6 > > Issue : We don't support the full Core 3, inputEncoding is a >core issue > Proposal : strike the inputEncoding part of the tests since this is >not an LS issue > > > Both tests have guards that should prevent them from running if hasFeature("Core", "3.0") is false. >6. DOMInputSourceTest5 > > Issue : incorrect test see: > Resolution : test will have to be rewritten > >http://lists.w3.org/Archives/Public/www-dom-ts/2003Dec/0035.html > > I've already rewritten it. >7. DOMWriterTest4 > > Issue : not implemented yet. > Resolution : we will implement this. > > >8. HasFeature4 > > Issue : test of domImpl.hasFeature("+lS", "3.0"); > we don't support the + since it is Core. > Resolution : see spec issues > > > Has L3 Core guard on it. If you are a L&S implementation that also supports L3 Core, you should return true for domImpl.hasFeature("+lS", "3.0")
Received on Tuesday, 30 December 2003 07:29:56 UTC