views:

228

answers:

2

I use C# code more-or-less like this to serialize an object to XML:

XmlSerializer xs1 = new XmlSerializer(typeof(YourClassName)); 
StreamWriter sw1 = new StreamWriter(@"c:\DeserializeYourObject.xml"); 
xs1.Serialize(sw1, objYourObjectFromYourClassName); 
sw1.Close(); 

I want it to serialize like this:

<ns0:Header xmlns:ns0="https://mynamespace/"&gt;
  <SchemaVersion>1.09</SchemaVersion>
  <DateTime>2009-12-15T00:00:01-08:00</DateTime>

but instead, it is doing this:

 <Header xmlns="https://mynamespace/"&gt;
    <SchemaVersion xmlns="">V109</SchemaVersion>
    <DateTime xmlns="">2010-03-08T18:21:09.100125-08:00</DateTime>

The way it is serializing doesn't work with the XPath I had planned to use, and doesn't match my BizTalk schema. Originally I built the class using XSD.exe from a BizTalk 2006 schema, then I use it for an argument to a WCF web service.

This might be related to an option called element FormDefault = Qualified or Unqualified. In BizTalk, my I have the schema set to "Unqualfiied" which is what I want.

Is there any way for the serializer to output "unqualified" results?

Thanks,

Neal Walters

Update:

Sample attribute on DateTime:

/// <remarks/>
[System.Xml.Serialization.XmlElementAttribute(Form = System.Xml.Schema.XmlSchemaForm.Unqualified)]
public System.DateTime DateTime
{
    get
    {
        return this.dateTimeField;
    }
    set
    {
        this.dateTimeField = value;
    }
}

BizTalk provides for what it calls promoted (or distinguished) fields, which use XPath to pull out values of individual elements. I checked the XPath of BizTalk in a tool called StylusStudio, and Biztalk'x xpath didn't work with the xmlns='' fields above.

The first thing my WCF web service does is to serialize the object to a string (using UTF16 encoding) and store it in an XML column in a SQL database. It is from there I am seeing the above xml sample with the xmlns="".

XPath:

/*[local-name()='Header' and namespace-uri()='https://mynamespace/']/*[local-name()='DateTime' and namespace-uri()='']
A: 

The XPATH you're using does not match the namespaces of your XML. Your Header element, for instance, in in the https://mynamespace/, but your XPATH is searching in the http://mynamespace/ namespace.

John Saunders
That was a typo already fixed. Like I said, I'm trying not to include the full blown sample - it's too big. I'm used to testing with Stylus Studio, similar to XMLSpy, but don't have yet at new client. But found this: http://www.mizar.dk/XPath/Default.aspx. I'm testing there now, both with the small example above, which seems to be working, and my real data, which is so far not working. I need a few minutes to experiment. Last night, in Stylus Studio it didn't work...
NealWalters
@Neal: fixed where? It's still in your question. BTW, I tested in XMLSpy, and the problem was immediately obvious.
John Saunders
A: 

My question was a bit muddled, so this answer may or may not help someone. This is a fairly complex scenario, and half of my issues came from trying to simplify it to make an easy post here.

I was actually adding a new element programmatically with a C# routine (see "NewElement" below). The C# code did not set its namespace to an empty string, therefore I believe it is inheriting the namespace of the "Header" element.

I freaked out a little because I was jumping to the conclusion that DateTime should not have the "xmlns=""' when in fact it should. Even though DateTime falls under Header, it does not nor should not inherit the Header's namespace.

In BizTalk, typically only complex types have their own namespace, and DateTime as well as NewElement are simple types.

 <Header xmlns="https://mynamespace/"&gt;
    <SchemaVersion xmlns="">V109</SchemaVersion>
    <DateTime xmlns="">2010-03-08T18:21:09.100125-08:00</DateTime>
    <NewElement>myvalue</NewElement>

So in effect, the two XML's I posted originally are identical as far as XPath goes. If I insert a new element, I need to make sure it follows the same pattern.

I had written the C# routine to add the element more than a year ago, and it worked fine then, so I wasn't suspect that it was causing this problem.

NealWalters