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 18:00:11 +0200
To: www-svg@w3.org
Message-ID: <op.tcv6qlh6gqiacl@gnorps.palace.opera.no>

Boris wrote:

> Dear SVG Working Group,
> It seems to me that the parseXML method on the SVGGlobal interface [1] is 
> somewhat underdefined.

The WG agrees and the section on parseXML has been updated:


     Given a string and a Document object, parse the string as an XML  
document and return a Node representing it. If the XML in the string is  
not well-formed according to either XML 1.0 or XML 1.1 or not  
namespace-well-formed according to Namespaces in XML 1.0 or Namespaces in  
XML 1.1 respectively, this method must return a null value.

     When parsing the input string, the contextDoc parameter is used only  
for setting the ownerDocument field in the parsed nodes.

     If during parsing a 'script' element is encountered, it must not be  
executed at that time. Script execution is deferred until the returned  
Document (or applicable parts thereof) is inserted into the contextDoc  

     There is no requirement to load any external resources, e.g. external  
entities, stylesheets, scripts, raster images, video, audio etc, for the  
parsing to complete. XSL stylesheets must not be applied.

     If the contextDoc parameter is defined, this method returns an Element  
object the ownerDocument field of which must be set to be the provided  
Document object. In effect when the contextDoc parameter is specified the  
processing must be equivalent to applying the following steps:

        1. parsing the XML into a Document
        2. retrieving its documentElement element
        3. calling importNode on the Document object passed to parseXML  
with the Element from the previous step as its first parameter and the  
deep parameter set to true. (Please note that importNode is part of DOM 3  
Core but not of the uDOM. It is mentioned here to indicate that the effect  
must be as if importNode had been used, but not to require that it be  
supported in implementations)
        4. return the result of the last step

         in DOMString data 	The data that is to be parsed as XML.
         in Document contextDoc 	The Document object in the context of  
which to perform the parsing.

     Return value
         Node 		A Node (either a Document or an Element) representing the  
content that was parsed.

         NOT_SUPPORTED_ERR: Raised if the type of node being imported is  
not supported.
         INVALID_CHARACTER_ERR: Raised if one of the imported names is not  
an XML name according to the XML version in use specified in the  
Document.xmlVersion attribute. This may happen when importing an XML 1.1  
[XML 1.1] element into an XML 1.0 document, for instance."

So to answer your questions:

> 1)  Are scripts executed if an <svg:script> tag is parsed?


> 2)  Are scripts executed if an <xhtml:script> tag is parsed?


> 3)  If the answer to question #1 or #2 is "yes", what global object
>      do they use?  What security context?  Does this depend on whether
>     a contextDoc was passed in?

Since the answer was 'no' on #1 and #2 that implies #3 is answered too.

> 4)  Are stylesheets loaded if an appropriate XML Processing Instruction
>      is parsed?  I'm including both CSS and XSLT stylesheets here.
> 5)  Are stylesheets loaded if an <svg:style> element is parsed?
> 6)  Are images loaded if an <svg:image> or <html:image> is parsed?
> 7)  Are subdocuments loaded if an <html:iframe> or equivalent is parsed?

No, there is no requirement to do so. This is not to say it's forbidden to  
preload these resources, but they shouldn't be applied (in the case of CSS  
and XSLT).

> 8)  Do the answers to questions 4-7 depend on whether a contextDoc
      was passed in?


> If the Working Group is interested, I can try to describe what the  
> equivalentsin Mozilla (DOMParser() and so forth) do as regards the  
> questions above (thoughI should note that some of the behavior there is  
> also underdefined and possiblysubject to change).

The WG would be happy to consider your proposed wording for a later  
revision of the specification.

Thank you
/Erik, on behalf of the SVG WG

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

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