The clear vision today is XHTML data traveling only one way from Office Word and InfoPath—from these Office clients to the service/server. There is no round-tripping for my sequences:
The Office Word sequence. Extract standards-compliant XHTML from Office Word and store it in a database as new data or an update of existing data. The only data returning from the database that would be necessary is some kind of identifier used to locate existing data for updates. Everything else is one way.
The InfoPath sequence. Open a blank form with multiple XHTML fields, fill it out and submit the root node to a Web service. Almost useless without rules to identify uniquely the data being submitted—not a show stopper but time consuming.
It seems obvious and tempting to expect InfoPath to query the Web service to return the new data through one “web method” for any additional editing but this is annoyingly inconvenient in the SP1 version of InfoPath. Why? InfoPath cannot ‘discover’ XHTML nodes ‘inside’ of an XML node emitted from one Web service member. The Web service has to provide multiple “web methods” that ‘tell’ InfoPath it is about to send XHTML. This means that instead of, say, sending one XML node with four XHTML child nodes, you would be forced to expose four “web methods” for each XHTML child node in addition to the other, un-rich text you wanted to send in the first place.
There is a Funky Knowledgebase article about this serious setback at SonghaySystem.com. I really did not know how serious this is until accepting my expectation that building XHTML editing into Microsoft applications is not a premium thing (worth several hundred from 3rd-party vendors) but an essential thing—like a browser with tabs. What the InfoPath team calls “rich” text is treated as a special, edge case, while the ‘real’ InfoPath users send bare naked text strings around just like in the days of DOS-based data entry systems. I assume that they are downplaying the importance of editing “rich” text (XHTML) until the technology catches up to my very valid needs. Okay, I’m drawn back into the XStandard.com ActiveX stuff.