I found it a little strange that attempting use the script to rename the <value> element as <NamespacePrefix:value> caused an error with LoadXML. However as you’ve demonstrated, <value xmlns=”myNamespace”> works just as well, so I’m not worrying about it.

Cheers
- Duane

I’m glad you figured it out! In case you’re still curious, this is the schema I used for my test (the namespace is different but as long as namespaces match, that shouldn’t matter). The listbox was bound to “$.BusinessName” which had to be specified manually in the “Object palette > Binding tab > Default Binding property”.

I will be blogging about multi-selection lists, namespaces and schemas shortly. I will provide a working sample along with a couple of caveats I have come across.

I was finally able to bind correctly to the schema – I was making a silly error in XMLSpy. The proper schema element for the listbox is as reported above (repeated here for clarity)

<xsd:element name=”AssociatedBusinessName” minOccurs=”0″ >
<xsd:complexType>
<xsd:sequence>
<xsd:element name=”value” type=”doc:TextType” minOccurs=”0″ maxOccurs=”unbounded’/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>

The binding on the field would be set to $.AssociatedBusinessName

Thanks for your help.
- Duane

Also a side point – I noticed that if I attempted to change the dataNode from
< value >
to
< doc:value > (as doc is my namespace prefix)
instead of < value xmlns=’myNamespace’ >
as you have in your sample, I got a General Error being thrown when it attempted to load the XML. Maybe it doesn’t like the colon?

- Duane

However, what did the schema you use look like for this element, and how did you bind it?

In my implementation, I’ve found that this works if the listbox is single-select, but if I change it to multi-select, then the dataNode is null.

Since it works properly in your sample – it must be because the element definition in the schemas are different (that’s the only thing I can think of).

Thanks
Duane

I asked some of my colleagues for help on this one and was able to find a workaround with John Brinkman’s help.

When a multi-selection is made in a list, its rawValue property stores the multi-selection as a new line (\n)-delimited list of strings (in the Form DOM). This value then gets stored in the Data DOM as a series of <value> nodes (as you already know).

Using a data node’s loadXML method, it’s possible to load arbitrary XML into a data node, replacing its current contents. Given this, you could write script in your list’s Exit event which parses the list’s rawValue property, builds an XML string of the properly-namespaced <doc:value> nodes and loads them into the listbox’s data node in the Data DOM:

// JavaScript (thanks John!):

// build XML string with wrapping <nodeValue> node:
var vList = ListBox1.rawValue.split("\n");
var sXML = "";
for (var i = 0; i < vList.length; i++)
{
    sXML += "<doc:value xmlns:doc='doc-namespace'>" +
        vList[i] + "</doc:value>";
}
sXML += "</nodeValue>";

// load content of <nodeValue> node into ListBox1's data node,
//  discarding root <nodeValue> node itself:
ListBox1.dataNode.loadXML(sXML, true, true);

The result would look like this, in the output data, assuming you had selected two items in ListBox1:

<?xml version="1.0" encoding="UTF-8"?>
<xfa:data xmlns:xfa="http://www.xfa.org/schema/xfa-data/1.0/">
   <doc:Application xmlns:doc="doc-namespace">
      <doc:AssociatedBusinessName>
         <doc:value>name1</doc:value>
         <doc:value>name2</doc:value>
      </doc:AssociatedBusinessName>
   </doc:Application>
</xfa:data>

Thanks! I don’t know if this is officially documented anywhere. It may be buried somewhere deep inside the XFA spec but I’m not sure.

Your timing is perfect as I’m preparing a blog post on schemas and mutli-selection lists though I had not considered the namespace issue with the generated <value> nodes.

I will investigate further and report back here when I get some answers.

This is a great post. Is this documented anywhere, I often feel like I’m missing a manual working with Designer.

Thanks again.