BTW, I’m not sure what we said about myXML.@foo = “baz” or myXML.@ba:foo = “baz”.
Are we mapping that to myXML.setChild(“@foo”,”baz”) and myXML.setChild(“@ba:foo”,”baz”), or are we creating a separate function for attributes? On Jan 5, 2016, at 5:07 PM, Harbs <harbs.li...@gmail.com> wrote: > Yes. I’m using DOMParser.parseFromString() to parse the XML. After the XML is > parsed into DOM elements, I’m walking that to create the XML structure. > > Although, I’m beginning to wonder if it makes more sense to just write my own > state machine to walk the XML and build the structure on my own. > > On Jan 5, 2016, at 4:53 PM, Andy Dufilie <andy.dufi...@gmail.com> wrote: > >> On Tue, Jan 5, 2016 at 9:37 AM, Harbs <harbs.li...@gmail.com> wrote: >> >>> That’s not going to work if you need to implement toXMLString(). >>> >>> Imagine an mxml file where all the CDATA becomes escaped text. It’s not >>> going to work very well… ;-) The same goes for lots of other XML file uses. >>> >>> Apparently this recommendation for DOM4 is not gonna happen, so we’re >>> good.[1] >>> >>> [1]https://github.com/whatwg/dom/issues/142 >>> >>> >> That's good news. However, I don't think toXMLString() would be a problem >> since you have to support escaped text anyway. Yes, it would be different >> from having the CDATA tag, but you would not lose any information other >> than the fact that there was a CDATA tag originally used to encode the >> text. The removal of CDATA was specific to HTML, not XML in general, and >> you can't put XML literals in JavaScript code anyway. Are you using a >> built-in JavaScript feature to parse the XML string and it doesn't support >> CDATA? >
