what to do about "programmed" divs

 on http://idweb.cloudapp.net:8080/Home/About, Ive brought back my full page - which adds necessary interactivity. After a quick success with Jurgens site (only posible by removing interactivity), it adds back on THAT particular page the ajax controls "so I can play with WANT/NEED SSL" (whatever that is). But I get the point, folks are trying to take https client SessionID management back into the app designers hands, and be able to control UI - so webid fits into the linked data world. I happen to playing with websso handshake for IDP guards, but later Ill play with SSL handshakes for webid in the same mode. Now, I fixed one bug in the sample code. It failed to "HTML encode" an href in the javascript the server fashioned - which upset the RDFa validator (but not the rest of the web). This was fun to fix, as the same code is also used server side when having the server pull metadata (rather than have the client pull the metadata). On the client, it needs one encoding (since its to be HTML validated within an href=""), and on the other it needs the alternative (url) encoding since there is no HTML wrapper. What I cannot get passed is the fact that the validator objects to placement of a div. Its a div that is is not even within the DOM. Its not even a div, as it stands, being the string "<div" inside a literal, that WILL become part of the DOM at runtime, once the javascript is evaluated. Whether the reuslting DIC will or will not be in a position legal for the DTD is not even know at this point (since it depends on the javascript coding, and run time paths). Is there some means in RDFa land to better "express" such literals in embedded, so they validate (and DONT get validated as is <div> in the DOM)? Its no too hard to make RDFa that works, on its own little page (though even that 2 weeks). Its harder to make RDFa as created by a servers-die control whose result can work inside normal HTML webapps, and still validate when the page is treated as a webid profile.