Tony - It's not, necessarily, implied that this plugin will return valid XML for an entire XML Document - instead, it's returning valid XML for an XML Document Fragment - which is perfectly "ok".
I mean, you can't expect $([ item1, item2 ]).toXML() to give you a valid XML document - and forcefully wrapping itself seems foolhardy. If it was so much of a concern, maybe there could be a .toXMLDocument() which returned a valid XML document instead of just a fragment. --John On 10/5/06, Antonio Collins <[EMAIL PROTECTED]> wrote: > I'm sorry but I don't agree with this plugin's name or usage. It simply > appends multiple valid xml together so the result could be invalid xml and > include multiple root elements. In my opinion, the result of any method > named .toXML() should be valid xml and the following tests should result in > valid XML documents. > > IE: domDoc.loadXML( $([ item1, item2 ]).toXML() ); > FF: (new DOMParser()).parseFromString( $([ item1, item2 ]).toXML(), > "text/xml" ); > > Tony Collins > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Christof Donat > Sent: Thursday, October 05, 2006 10:02 AM > To: jQuery Discussion. > Subject: Re: [jQuery] New plugin: toXML (XML serializer) > > Hi, > > > The thing is, the main use case for a toXML() call is to send XML data > > via an ajax request. > > Well, I could imagine that there may be other usecases as well, like doing > search and replace operations on the string representation of a XML which is > reparsed afterwards. It was just a joke, but you may look at that "use case" > > which could be usefull for XML-Data as well: > > http://dean.edwards.name/weblog/2006/07/erlaubt/#comment7262 > > > The duration of the request greatly overshadows any optimisation that > > could be applied to toXML. > > Well, there are also use cases, where you can assume a really fast network > connections (inhouse with 1GB-Ethernet e.g.) and thus work with huge > datasets on the client side. Then suddenly the time, the client and server > need to process the request becomes the dominating factor. > > I think that jQuery could also be really usefull for Applications using > XULrunner (I haven't tried yet) and thus there are many other use cases like > e.g. working with RDF-Data, etc. - OK, we don't need to emulate > XMLSerializer then. > > > Also, I don't think it is a good idea to attempt to implement an > > XMLSerializer object for the sake of it, especially when the full > > interface isn't being implemented > > You are right here of course. I was too lazy to look for the > XMLSerializer-interface and see if the other functions can also be simulated > so easy. > > > As a rule I live by the KISS principle, and never optimise code unless > > it becomes a bottleneck, and then only do so under profiling conditions. > > Well, KISS is an optimization strategy :-) Most of the time code is fast > when it is simple, but "most of the time" is not "always". > > Christof > > _______________________________________________ > jQuery mailing list > discuss@jquery.com > http://jquery.com/discuss/ > > > _______________________________________________ > jQuery mailing list > discuss@jquery.com > http://jquery.com/discuss/ > -- John Resig http://ejohn.org/ [EMAIL PROTECTED] _______________________________________________ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
