InfoPath 2007 multiple XSD's in 1 form problems

[Sebastian Ramirez]

I cannot add XSD elements to an XSD any element in my form if the XSD I am
trying to add has the same namespace as an XSD already in the form. I can
add it through editing the manifest.xsf and it will open up in form edit mode
and work, but I keep getting an error whenever I open up the xsn in design
mode. If all the schemas added to the form are from different namespaces
there is no problem:

error -

“The form template contains more than one XML Schema that use the same
namespace, which is not allowed.â€

Example offending xml in manifest.xsf.

<xsf:documentSchemas>
<xsf:documentSchema rootSchema="yes"
location="http://www.witsml.org/schemas/131
el_opsReport.xsd"></xsf:documentSchema>

<xsf:documentSchema
location="http://www.bakerhughes.com/schemas/100
el_opsReportINTEQ.xsd"></xsf:documentSchema>

<xsf:documentSchema
location="http://www.bakerhughes.com/schemas/100
el_bhaRunINTEQ.xsd"></xsf:documentSchema>

</xsf:documentSchemas>



Is this an InfoPath limitation with no workaround, should I stop banging my
head against this?

 

[Gavin McKay]

Hello,

What do you mean by "form edit mode" and "design mode"? Do you mean the
preview mode works, but designing the form gives you the error? It could be
a limitation with the designer, I don't know.

Can I ask why you are manually adding elements to the schema? Perhaps there
is another way to solve your problem.

Gavin.

 

[Sebastian Ramirez]

Thanks for the reply Gavin.

I am really trying to make sure that this is a problem so a software
architecture review won't come up with "Hey Sebastian that was stupid you
should do it this way for it to work." I am pretty sure that this is a
problem with no solution but I want to make sure.

When I say Form edit mode I mean editing a form created from the template in
the InfoPath viewer, design mode is editing the template.

My problem is basiacllay this.

Assume XSD's A and B both in namespace X. A has an element called
"additional" which is defined as an xsd:any type. I build a form based on
XSD A then want to add XSD B to "additional" in the form. This does not work
through the designer. If I edit the InfoPath source files for the form to
make it work I get that error when trying to load the template into the
designer, though a form executed against the manually edited template works
fine.

The xsd:any is the W3C recommended approach to augmenting/extending XSD
comples types that is being utilized by the standards body I get the XSD's
from: httep://www.witsml.org. So unfortunately I can not change it.

I do have a solution involving creating my own schema and then utilizing an
XSLT to make it map to the standard but Its really annoying to have to do
this.

My investigation indicates that the namespace is being utilized by InfoPath
as the primary key for a main schema included in a data source. Which limits
me to either have a namespace for each piece I want to add into an xsd:any or
use the approach I mentioned above with the XSLT.

Thanks for the reply,

 

[Gavin McKay]

Hi Sebastian,

Sorry, I can't comment about XSDs to resolve your problem. I am guessing
you are correct with your assumptions on how Infopath handles XSDs
internally, someone else on this forum might have an answer.

However if the namespaces are the same, then it sounds like you would have
to annotate your schema to change the namespace and create a transform to
convert it. In theory the transform shouldn't be too complex, wouldn't you
just be able to transform your "mapped" schema back to what you actually want
by modifying the root schema node in the transform? Sorry I'm not familiar
with witsml.org so it is probably quite a bit more complex!

While quite powerful, Infopath is a simple creature. I tend to shy away
from any manual modification of schemas because it seems quite easy to get
Infopath upset, as you've no doubt found out!

Gavin.

 

[Sebastian Ramirez]

Gavin you ae absolutely correct.

I have to make a transform anyway because InfoPath seems to use a direct
connect to the instance of XML for a particular form for data bindings rather
than a mapped instance. Basically I have minOccurs="0" in the schemas I am
using, unfortunately the standards body rejects the idea of making the
elements nillable, therefore InfoPath either always comes up with an error if
I bind the element to a textbox, or requires me to delete it from the schema
which loses the binding. Wither way I am looking at a customized schema that
will look similar but not be exactly the same as my target schema.

This issue with the namespace is really just one of the problems, but since
it is not documented in InfoPath as one of its "features" I have nothing to
point the architecture audit committee to explain my decisions in this matter.

Anyways thanks for the interest. If I discover anything new related to this
problem I will post it in this forum.

- Sebastian Ramirez

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

 

[Gavin McKay]

Hi Sebastian,

If you could post any findings you make here that would be wonderful! I
know Infopath doesn't like "complex" schemas to bind to - for example, trying
to bind complex (Collection-based in particular) web services via Windows
Communication Foundation (WCF .NET 3.0) isn't supported in Infopath. Pity,
would be wonderful to be able to submit directly with this level of
complexity. My solution at the moment is probably going to be similar to
yours i.e. write custom code to submit/transform the data.

Gavin.

 

[Sebastian Ramirez]

Well the mystery is solved.

According to a Microsoft InfoPath evangelist and sources he contacted in the
InfoPath product development group, InfoPath cannot handle more than 1 Schema
per namespace when the schema is added to a data source. Therfore if you
want to insert additional schemas in a sequence (i.e. xs:any or xsd:any) they
must have distinct namespaces because the way InfoPath lookups were developed.