- From: Jonathan Watt <jwatt@jwatt.org>
- Date: Fri, 27 Jan 2006 17:23:36 +0000
- To: www-svg@w3.org
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