Inserting XML into an HTML document

What are you trying to do that requires a nested xml doc? I wonder if there is an alternate solution to the same problem that doesn't require relying on the browser to handle a namespaced xml correctly.

Also, note that doing this is "illegal" under XHTML (if you turned the DOM you got back into text and tried to vaidate it, it wouldn't.)

I do not want to transform to XHTML because I wish to send the DocBook document back to the server with user edits. Please elucidate re: IFrame. I thought frames were considered a no-no. I've successfully argued that we need not support non-compliant browsers: it's too costly. Ergo, if it works with Webkit and Presto, and Mozilla if it's not a handicap, it's all good. MSIE is dead to me.

So frame-based layouts are a no-no for a number of reasons: primarily, because they break the "URL -> content" mapping of the Internet (when you go to a frame-based page, you see multiple documents at a time, and the URL at the top of your browser doesn't have much relation to the content). But IFrames have actually gotten a lot of love since this whole AJAX thing got started, since they're a very flexible way of including different documents on the same page, and they let you do all manner of neat things (even when hidden) with respect to server-side communication from JavaScript. But that's all sort of beside the point for you. What you want to do is load a document inside another document, and that's exactly what IFrames were originally designed for. Plus, if this is an issue for you, you can make them border-less, to "seamlessly" integrate the content with the rest of the page. And, as long as the XML document is served from the same domain as the containing XHTML document, JavaScript running on the outer page will have access to the XML document inside the IFrame, in case you decide you do need to read it.

And just to clarify, you'd include the document thus. At the place in the page you want the XML document to show up:<iframe src="path/to/xmldoc"></iframe>and that's it.

AFAIK, the XML loading thing I'm using already tosses the document into an IFrame (a hidden one, I guess). I'll play around with unhiding it and all that. Thanks! How about the idea of a non-transforming XSLT to insert the document directly into the XHTML? Any validity to that? And why on earth hasn't this become de riguer? I am astounded that no one's serving DocBook directly to the browser, let alone allowing the end user to click on a paragraph to edit it. Seems like a perfectly natural hook-up to me.

Can you show us a page, even a mockup, of what you're trying to do? I'm confused -- you want to serve XML directly to a web browser, and you want users to be able to edit it? And you wonder why this isn't happening all the time? Well, because browsers don't do XML, that's why. They do HTML. And because data-editing tasks in browsers are done using forms. Maybe there's something I'm missing about this. You have some data on the back end, and you want to present it to the user for editing, then send it back. That's trivial, but your idea that it should be done by dumping XML into the DOM is pretty ... unusual.

Modern browsers do XML. And XSLT. And sophisticated Javascript DOM. Everything I want is right there for the plucking, as evidenced by the fact that I — a lowly retard when it comes to this sort of thing — am doing it. I've successfully had click-to-edit on individual block elements, ie. paragraphs, said edits being sent back to the server to be integrated into the source text based on the ID of the selected block. This will be much the same, only instead of having to screw around with inserting ID attributes on all the block elements, I can just send back the entire DocBook text, trusting SVN or GIT or whatever to do a proper integration of the modified text back into the source. At this point I'm figuring I'm either some sort of genius, or am batshitinsane. Either way, I expect it to work in the end. :-)

Considering that a browser won't display anything more than what HTML does then, to me, it seems that putting DocBook XML in the page and styling with CSS is an unnecessary task. It would easier to transform the DocBook and bind the resulting HTML to the page. You could transform DocBook XML nodes into div/span and @class names (perhaps prefixed with "db:" ... class attributes in HTML of course aren't just for CSS they're generic ways of marking up areas of the page). That would allow you to understand which part of the page was changed, old-browser compatibility, etc. The deviation from HTML prevents you from using WYSIWYG editors (or considering you're using DocBook, WYSIWYM) Although you could do XSLT in the browser you could also do it on the server and just include that as part of the page generation. You could transform it on the server in order to get a wider range of browsers. XSLT features disable in Firefox like 'text escaping', and I'm told that XSLT 2.0 features aren't in browsers yet. So why involve JavaScript in the XSLT? The only part that seems to warrant JavaScript is the clicking and sending back data and forth. This project sounds like it could be a lot simpler whilst still maintaining the elegance of DocBook (just keep it server-side). Perhaps one reason why DocBook isn't popular in the browser is that there's more to it than CSS. Search engines and accessibility tools can parse HTML, but not DocBook. You can only emulate browser functionality -- eg, you can't actually click on a DocBook hyperlink because a browser doesn't understand that element, so instead you are (presumably) attaching onclick events to the node. Sorry if I sound a bit down on your project, but I've been trying lots of XML architectures over the years and I've attempted things like this before. Putting the transformation and DocBook in the browser is an unnecessary challenge, IMO.