Re: Comments on DOM 3 LS

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 19 July 2003 12:00 am, Anjana Manian wrote:
> 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.

I agree.

> 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.

Well, DOMBuilder makes really sense to me since it does not *parse* the DOM 
but *builds* the DOM by *parsing* XML input.

My vote is for getting back into DOMBuilder(!).

Or tell my some good reasons (as Anjana wrote, too) *why* you've renamed it.

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

This looks ugly although I really do not know why you already have a DOMParser 
in your implementation, Anjana. What does it do when it doesn't do what the 
old DOMBuilder does?

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

I read somewhere that it extra module may be either implemented using 
getFeature or by subclassing interfaces. So I did this on DOMParser with 
EventTarget, too. Everything else doesn't make any sense. They surely meant 
this ;)

> 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.

It is possible to implement one DOMBuilder doing both jobs, synchronous and 
asynchronous parsing of input. It's just a question of the entry method that 
the API provides.

> - 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.

I agree, this needs to be clarified, too. I just fire one progress even at the 
very beginnning, than each end of element a new progress event, and a load 
event at the very end of document.

One thing not clear in the spec is, are they only fired when the parser is in 
async mode or even in sync mode (since a background thread still can listen 
on it). 

Furthermore, it is not clarified how parseWithContext interacts with the 
DOMBuilderFilter/DOMParserFilter and its very own passed ACTION TYPE. Which 
one gets precedance? Or will the filter be ignored and interpreded as accept?

Yet another thing not clear to me is *how many* does parseWithContext read 
from the input? up to the end (EOF)?
If not, how many? when to stop? when not?

> - "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.

Just as I have understood them, DOMConfiguration is the base class of any 
other DOMConfiguration, so a default DOMParser overrides the default 
DOMConfiguration parameters and the same for DOMSerializer.
The best thing to fit in for me was to subclass DOMConfiguration to 
DOMParserConfiguration and DOMSerializerConfiguration since even setParameter 
and canSetParameter do react in different ways (at least the parser config).

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

and my question is: *WHY* didn't you keep the name DOMEntityResolver?

> 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 the opposite to the DOMParser renaming I really vote for that name 
DOMSerializer. since this makes sense in comparison to other serializers 
(like in cocoon, writing is also called serializing).

Please note, that there is a DOMReader that does exactly the opposite as the 
now existing DOMWriter. This is more than intuitive to have them named in 
that way :)

>
> - "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.

This is right what you say and wrong that it is in that way ;) They must have 
lost this *heh*

6.) I really bed that someone responsible will reply before 2010.

Greetings,
Christian Parpart.

- -- 
 15:38:22 up 62 days,  6:46,  0 users,  load average: 0.00, 0.00, 0.00







-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/G/JNPpa2GmDVhK0RAtiUAJ4kfVIzWU1BGqUwY/8PFll8RdcqAQCdHBlj
pMD07VjlCBSmleVDBWEv+Vs=
=DHSp
-----END PGP SIGNATURE-----

Received on Monday, 21 July 2003 09:58:15 UTC