W3C home > Mailing lists > Public > www-svg@w3.org > July 2006

Re: [SVGMobile12] parseXML method needs clarification

From: Erik Dahlström <ed@opera.com>
Date: Tue, 18 Jul 2006 19:21:45 +0200
To: "Boris Zbarsky" <bzbarsky@mit.edu>
Cc: www-svg@w3.org
Message-ID: <op.tcwaij09gqiacl@gnorps.palace.opera.no>

On Tue, 18 Jul 2006 18:50:07 +0200, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> Erik Dahlström wrote:
>> Ok, so would this wording satisfy you:
>> "If during parsing a 'script' element is encountered, it must not be
>> executed at that time. Script execution for that element is deferred  
>> until
>> it is inserted into the contextDoc document."
> It's better, though it ignores what happens with a null contextDoc and  
> adoptNode followed by insertion into some other document...  Probably  
> good enough to get the intent across, at least.

I had some trouble expressing it in a straightforward way, but yes, what  
you're saying is what the intent is.

>> Leftovers from old days I presume, would the following wording be ok:
>> "NOT_SUPPORTED_ERR: Raised by importNode if the type of node being  
>> imported is not supported."
> What does importNode have to do with this?  Or do you refer to the  
> operation that's "not importNode but acts like it"?  The way things are  
> phrased right now sounds like these exceptions need not be thrown if  
> there's no actual importNode involved; is that the desired effect?

The text "when the contextDoc parameter is specified the processing must  
be equivalent to applying the following steps" does suggest that since  
importNode is used, an equivalent solution would have to throw exceptions  
for the same reasons importNode does. But I guess one could make other  
interpretations too, so what do you suggest?

One way would be to remove the exceptions by wrapping the call to  
importNode in a try-catch statement. Would that be better?


Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Received on Tuesday, 18 July 2006 17:21:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:08 UTC