Comments on DOM 3 LS

Comments on DOM Level 3 Load and Save specification based on the June 19 version of the spec. 

1. Interface DOMImplementationLS: 
   An api to create DOMOutput needs to be included.

2. Interface DOMParser:

- This interface was called DOMBuilder in the earlier version(s) of the spec. Is there any specific reason why the name is changed to DOMParser. The name change to "DOMParser" is confusing to our users since we already have a public class called DOMParser (oracle.xml.parser.v2.DOMParser) and from a quick google search, it looks like Xerces might also have one (namely org.apache.xerces.parser.DOMParser )  If there is no "specific" reason for changing the name to DOMParser, it will be preferred if the name is changed back to DOMBuilder. 

Alternatively, the interface could be changed to DOMParserLS or DOMBuilderLS (consistent with DOMImplementationLS, DocumentLS etc).

- "Asynchronous DOMParser objects are expected to also implement the events::EventTarget interface so that event listener can be registered on asynchronous DOMParser objects": 

It will be much cleaner and clearer if DOMParser extends events:EventTarget interface instead of expecting the implementation to extend and support EventTarget. It could be argued that synchronous DOMParser is not required to implement the events::EventTarget and so it should not be a forced to implement one. In that case, a possible solution is to have a generic DOMParser interface and two other interfaces namely DOMParserSynchronous and DOMParserAsynchronous which extends DOMParser. Then the DOMParserAsynchronous could be made to implement the events::EventTarget interface. 

- The spec is not very clear when the progress events are fired. Probably, the spec should include some scenarios when the progress event should be fired or should include a sentence saying that signaling of progress events is implementation dependent. 

- "In addition to the parameters recognized in DOM Level 3 Core...": 
   - Does this mean that all the parameters listed in DOMConfiguration interface in DOM Level 3 needs to be recognized by DOM LS implementation?
   - If yes, then some of the parameters are repeated here like "infoset", "namespace" etc. They need to be removed. 
   - If not, it should be explicitly stated which parameters (if any) from DOM Level 3 Core needs to be recognized by DOM LS module. 
 
3. Interface DOMResourceResolver

- DOMParser does not have the attribute entity resolver. Therefore, it is not clear how the DOMResourceResolver is associated with the DOMParser.

4. Interface DOMSerializer:

- Is there any specific reason why DOMWriter is changed to DOMSerializer. It will be preferred if DOMSerializer is changed to DOMSerializerLS or to DOMWriterLS. 

- "In addition to the parameters ... " - same comment as in DOMParser.

5. Interface DOMOutput 

- "The application can either provide its own objects that implement this interface, or it can use the generic factory method DOMImplementationLS.createDOMOutput() to create objects that implement this interface." - DOMImplementationLS does not have a factory method to create DOMOutput. 

Thanks,
Anjana

Received on Friday, 18 July 2003 18:21:04 UTC