[SVGMobile12] A.7.19 parseXML

Dear SVG WG,

http://www.w3.org/TR/SVGMobile12/svgudom.html#svg::SVGGlobal_parseXML in section 
A.7.19. There are many issues with this function.

1) There is no means to specify the MIME type the string should be parsed as.

Mozilla decides on the type of document object to create depending on the MIME 
type served with markup. (I understand the same has to be true for Safari if the 
content has no DOCTYPE declaration, which will be the case for SVG 1.2.) 
Although I don't know this part of Mozilla/Safari's code, I'm told that 
rearchitecting would be a *huge* and messy task and the owners of this code 
aren't even sure if the end result is desirable. If waiting until you've parsed 
the root element is too late to create it's ownerDocument, I think the burden 
would be better placed on content authors to change parseXML in their code to a 
better spec'ed parsing function. That is if they want a built-in parseXML any 
time in the next three years or more.

I assume the SVG implementations that established the parseXML extension were 
able to bypass this problem because they only dealt with SVG and therefore 
assumed image/svg+xml.

The above is my main issue, but here are some others:

2) By default, this function assumes you want to create a new document.

However SVG Tiny 1.2 doesn't support having more than one document as far as I 
can tell. Certainly createDocument is not part of SVG 1.2 Tiny's cut down 
DOMImplementation interface, and there may be issues that allowing document 
objects to be created via this route could raise.

I also think the assumption that you want to create a new document is false - 
most people will want to parse markup and insert it into the *current* document, 
not have to specify the current document explicitly or importNode() where it's 
available. Either that, or they don't care about the ownerDocument of the new 
nodes so it would be better to make it the current document and save the 
overhead of creating a new document.

3) The function is incompatible with existing implementations anyway.

When a document is passed in, current implementations return a DocumentFragment. 
This allows the markup string to have multiple sibling tags at it's root, 
whereas the version here has a different return type that would disallow this.

4) Behavior for invalid markup is unspecified.

When you pass invalid markup to DOMParser in Mozilla it will create 
<parsererror> elements in place of the invalid markup. I don't know if Opera and 
Safari do the same with their implementations of DOMParser, but if they do I 
think it would be better to spec DOMParser rather than this broken function 
parseXML. At least specify that it throws or something.

Regards,
Jonathan

Received on Friday, 27 January 2006 17:24:36 UTC