qualified v/s unqualified elements

[Sameer Pradhan <sameerp@us.fujitsu.com>]

All,

 

I think this is the number one problem to solve right now: qualified v/s unqualified elements.

 

Jeff, the behaviour you mention below is specified by XML Schema.

.NET is just faithfully following the XML Schema specification.

Please refer to XML Schema Primer; Section 3: Namespaces, Schemas & Qualification

http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/#NS

 

We need to make sure that other implementers don't run into the same problem.

 

I believe the answer is that we should use our asap.xsd to MANDATE that ASAP elements be qualified.

And that ASAP messages must conform to asap.xsd

Then we can be sure that all VALID Asap messages will have qualified ASAP elements.

 

 

Next question is the qualified/unqualified-ness of context/result data elements.

 

One alternative is to let the context/result data schemas provided by the various implementers specify whether the context/result data elements should be qualified or not.

 

Second alternative is that the ASAP spec RECOMMEND that the context/result data schemas provided by the various implementers specify that the context/result data elements should be qualified.

 

I prefer the first alternative, because it allows implementers flexibility about how their context/result data should exactly look like. Downside is that ASAP implementers need to be careful to respect the qualified-ness specified by the context/result data schemas.

 

I don't know yet how exactly to go about doing all this. I am still researching it. Comments/suggestions/pointers are welcome. A solution is most welcome. J

 

BTW, John Fuller told me that he has changed his code to have everything qualified, and that he will deploy that code outside the firewall on Monday.

 

Let us put our heads together and try to resolve this before the next conf call.

 

Thanks,

Sameer

 

 

-----Original Message-----
From: Jeff Cohen [mailto:jeffc42@bayarea.net]
Sent: Tuesday, May 18, 2004 9:38 PM
To: Sameer Pradhan
Cc: 'Jfuller@Wernervas. Com'; Keith Swenson
Subject: RE: .NET client and i-Flow ASAP both up on internet machine

 

This just gets better. .NET apparently has no flexibility in handling namespace prefixes.  If elements are declared to be qualified, it won't work if they're not.  If they are declared to be unqualified, they won't work if they are.

 

Here's the big problem. The i-Flow responses have everything qualified.  But John's responses have numerous elements that are not qualified.  It appears impossible to get  .NET to accept both of them simultaneously.  According to the docs, Microsoft appears to think that the presence or absence of qualifiers is determined by the schema and so it is correct to enforce it.  The WSDL we started with apparently declares all elements to be unqualified.  I'm stuck.