The other day I posted about my initial experiences with InfoPath. As I mentioned, one of the frustrating things I found was that for the body text, whose type was string, I couldn't use the RichTextBox.

Don shared some insight as to why this is the case.

The rich text control can only be bound to an element whose type looks like this:

<complexType mixed="true">
<sequence minOccurs="0" maxOccurs="unbounded" >
<any namespace="http://www.w3.org/1999/xhtml"
processContents="lax" />
</sequence>
</complexType>

As it turns out, the problem is that this particular service uses a string for that field. At first I accepted that answer, but the more I think about it, the more it bothers me. I'm assuming the RichTextBox produces an XHTML. An HTML string, whether well-formed or not, is still just a string at the end of the day. If the underlying data type is perfectly valid, why shouldn't I be able to use RichTextBox?

At the very least, I'm hoping I can do some sort of mapping. If I can create a new "virtual" data field on my end, bind the RichTextBox to it, and then provide some mapping logic to the underlying object (ie escaping XML characters or wrapping it in CDATA), that would be neat. I'm going to keep my fingers crossed and play with it a little this weekend.

The thing is, I really do think it's important for a tool such as InfoPath to be flexible. I realize this may be a contrived example to some extent... but when I design a form, I should be able to choose how to build the string. I shouldn't be limited to a simple textbox. More importantly, we shouldn't have to design services based on their potential consumers.

Can anyone (Don especially) add more insight into this problem? Am I missing something here? Are there valid technical reasons why this shouldn't be the case?