Problem With InfoPath 2007 and SharePoint Namespace Handling

I was working with some InfoPath 2007 + MOSS 2007 + BizTalk Server 2006 R2 scenarios, and accidentally came across a possible problem with how InfoPath is managing namespaces for promoted columns.

Now I suspect the problem is actually “me”, since the scenario I’m outlining below seems to be too big of a problem otherwise. Let’s assume I have a very simple XSD schema which I will use to build an InfoPath form which in turn, is published to SharePoint. My schema looks like this …

Given that schema (notice ElementFormDefault is set to Qualified) the following two instances are considered equivalent.



Whether there’s a namespace prefix on the element or not doesn’t matter. And as with any BizTalk-developed schema, there is no default namespace prefix set on this XSD. Next, I went to my InfoPath 2003 + SharePoint 2003 + BizTalk Server 2006 environment to build an InfoPath form based on this schema.

During the publication of this form to SharePoint, I specified two elements from my XSD that I wish to display as columns in the SharePoint document library.

Just to peek at how these elements are promoted, I decided to “unpack” the InfoPath form and look at the source files.

If you look inside the manifest.xsf file, you’d fine a node where the promoted columns are referenced.

<xsf:listProperties>
	<xsf:fields>
		<xsf:field name="Age" 
		columnName="{...}" 
		node="/ns1:Person/ns1:Age" type="xsd:string">
		</xsf:field>
		<xsf:field name="State" 
		columnName="{...}" 
		node="/ns1:Person/ns1:State" type="xsd:string">
		</xsf:field>
	</xsf:fields>
</xsf:listProperties>

A namespace prefix (defined at the top of the manifest file) is used here (ns1). If I upload the two XML files I showed above (one with a namespace prefix for the elements, the other without), I still get the promoted values I was seeking since a particular namespace prefix should be irrelevant.

That’s the behavior that I’m used to, and have developed around. When BizTalk publishes these documents to this library, the same result (promoted columns) occurs.

Now let’s switch to the InfoPath 2007 + MOSS 2007 environment and build the same solution. Taking the exact same XSD schema and XML instances, I went ahead and built an InfoPath 2007 form and selected to publish it to the MOSS server.

While I have InfoPath Forms Server configured, this particular form was not set up to use it. Like my InfoPath 2003 form, this form has the same columns promoted.

However, after publishing to MOSS, and uploading my two XML instance files, I have NO promoted values!

Just in case “ns0” is already used, I created two more instance files, one with a namespace prefix of “foo” and one with a namespace prefix of “ns1.” Only using a namespace prefix of ns1 results in the XML elements getting promoted.

If I unpack the InfoPath 2007 form, the node in the manifest representing the promoted columns has identical syntax to the InfoPath 2003 form. If I fill out the InfoPath form from the MOSS document library directly, the columns ARE promoted, but peeking at the underlying XML shows that a default namespace of ns1 is used.

So what’s going on here? I can’t buy that you HAVE to use “ns1” as the namespace prefix in order to promote columns in InfoPath 2007 + MOSS when InfoPath 2003 + SharePoint doesn’t require this (arbitrary) behavior. The prefix should be irrelevant.

Did I miss a (new) step in the MOSS environment? Does my schema require something different? Does this appear to be an InfoPath thing or SharePoint thing? Am I just a monkey?

I noticed this when publishing messages from BizTalk Server 2006 R2 to SharePoint and being unable to get the promoted values to show up. I really find it silly to have to worry about setting up explicit namespace prefixes. Any thoughts are appreciated.

Technorati Tags: ,



Categories: InfoPath, SharePoint

14 replies

  1. Its a bug in WSS/MOSS. The two solutions are:
    a) make a custom XSLT that uses the right namespace URI prefixes.
    b) write a custom WSS adapter.

  2. Wow, that’s quite a bug. I’m glad that I’m less crazy than previously thought.

    Thanks Jon.

  3. Hey All. I am encountering the same problem from a different angle. When I programatically create an InfoPath form instance and save it to a document library, the form exhibits strange behavior. If you look at the xml that’s serialized, the default namespace (which should be “my”) is blank and all elements are not prefixed.

    Bugger!

  4. Wow, I’ve run into exactly the same scenario. Please keep up us posted if you find a better workaround that writing a custom xslt or wss adapter. One would think that MS would issue a bug fix ASAP!

    Thanks

  5. This bug seems to happen with WSS3 regardless of wether or not you are using InfoPath 2003 or 2007. I think I found another work around. After creating the Form in InfoPath extract the files. Open the mainfest in notepad and do a find-replace on NS1 changing it to NS0. Save the file and then click on it and open in InfoPath. It should open the form – then publish to your library and give it a try. It seems to work…somebody else try to make sure I am not crazy.

  6. You can create a simple BizTalk project and Orchestration must be AUTOMIC. Then add Recei shape, Construct Shape, Message assignment,Send Shape.

    Code in the Message Assignment Shape.

    WSSout=NewForm;
    NodeList=WSSout.GetElementsByTagName(“ns0:Form”);
    Node1=NodeList.Item(0);
    Node1.Prefix=”ns1″;
    WSSInput=WSSout;

    NewForm is the message generated by BizTalk with ns0:Form.
    WSSout is a variable of type System.Xml.XmlDocument
    NodeList is a variable of type System.Xml.XmlNodeList
    Node1 is a variable of type System.Xml.XmlNode
    WSSInput is a message type of System.Xml.XmlDocument

    The input will be ns0:Form na doutput will be ns1:Form .
    You can create this as a Convertion project and deploy so the flow will be Input to BizTalk –> output from BizTalk is Input to the project we created –> Output from Our project is the Input to MOSS 🙂. Hope this help.

    If anyone has any other ideas please post.

    Regards,
    Daniel.

  7. i’m having the same problem too..don’t know how to configure this. it seems like the infopath 2007 really mess up my working life..

  8. Well, I think that I’m seeing it in BizTalk Server 2009.
    I’ll keep trying and report back.

  9. This is still a problem in bts 2009 – unfortunatly.

    But @Dave’s method of modifying the manifest file works for me as well. Strange…

  10. We have resolved this issue for about 46 different InfoPath templates and multiple levels of nesting. Please let me know if anyone is intrested in solution.

  11. Hemendra Patel, yes please post your solutions

Trackbacks

  1. InfoPath 2007 Scenarios With BizTalk Server 2006 R2 « Richard Seroter’s Architecture Musings

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: