Content-Type: multipart/alternative; boundary="----=_NextPart_001_0017_01CA4A8F.E0C5D240" ------=_NextPart_001_0017_01CA4A8F.E0C5D240 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Michael Attached is a small Zip file with a C# console app that reproduces the problem for a very simple case. The problem is (I think) as you suspected; i.e., associated with the provenance of the input XML doc. In my case I start with an XDocument which is in the System.Xml.Linq namespace. My code converts this to an XmlDocument by creating a reader off that XDocument and feeding the reader to the Load method of the new XmlDocument. At this point the XmlDocument looks fine; i.e., the namespace is there as expected. The next step is to convert it to an XdmNode and that's where things go wrong. I suggest just putting a breakpoint on the last line of the code, then examining the inputXML variable vs. the input variable. This should be straightforward using Visual Studio Express. To get this to run you'll probably need to fix the reference to the saxonapi dll as I set this up to point to one off in the "real" project file structure. This app also assumes the 3.5 .Net framework. Regards, Bill From: Michael Kay [mailto:mike@saxonica.com] Sent: Friday, October 09, 2009 3:44 PM To: cohagan@acm.org; 'Mailing list for the SAXON XSLT and XQuery processor' Subject: RE: [saxon] Wrap() method is not preserving default namespace spec? I've produced a simple test that tries to reproduce this, and it works correctly for me. So we need to reproduce the circumstances under which the failure occurs. Could you please try to put together a little application that demonstrates the problem? It will also be necessary to know exactly what software versions you are using. There don't seem to be any known bugs in this area. However, most of my testing (including the test mentioned above) has been with XmlDocument instances generated directly by parsing source XML documents. Experience with the Java product suggests that most of the problems with wrapping a DOM come when the DOM is constructed programmatically. There are many different ways of building a DOM, including many ways of creating structures that will never be produced directly by the XML parser. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay _____ From: Bill Cohagan [mailto:cohagan@acm.org] Sent: 09 October 2009 19:15 To: 'Mailing list for the SAXON XSLT and XQuery processor' Subject: [saxon] Wrap() method is not preserving default namespace spec? I'm running saxonb9-1-0-5n and having problems converting a System.Xml.XmlDocument -> XdmNode via the DocumentBuilder.Wrap method. The code in question is: XdmNode inputXML = processor.NewDocumentBuilder().Wrap(input); Examining the "input" (XmlDocument) shows an XML doc with the following top level element: Examining the inputXML XdmNode after the call to Wrap shows an XdmNode with the following top level element: So, the question is, WHAT THE HECK HAPPENED TO THE DEFAULT NAMESPACE SPEC? Obviously this is causing problems in the subsequent XSL transform processing. Please advise, Bill ------=_NextPart_001_0017_01CA4A8F.E0C5D240 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Michael

 

  Attached is a = small Zip file with a C# console app that reproduces the problem for a very simple case.  The problem is (I think) as you suspected; i.e., associated = with the provenance of the input XML doc.  In my case I start with an = XDocument which is in the System.Xml.Linq namespace. My code converts this to an XmlDocument by creating a reader off that XDocument and feeding the = reader to the Load method of the new XmlDocument. At this point the XmlDocument = looks fine; i.e., the namespace is there as expected. The next step is to = convert it to an XdmNode and that’s where things go = wrong.

 

  I suggest just = putting a breakpoint on the last line of the code, then examining the inputXML = variable vs. the input variable. This should be straightforward using Visual = Studio Express.

 

  To get this to = run you’ll probably need to fix the reference to the saxonapi dll as I set this up = to point to one off in the “real” project file structure. This app = also assumes the 3.5 .Net framework.

 

Regards,

 Bill

 

From:= Michael = Kay [mailto:mike@saxonica.com]
Sent: Friday, October 09, 2009 3:44 PM
To: cohagan@acm.org; 'Mailing list for the SAXON XSLT and XQuery processor'
Subject: RE: [saxon] Wrap() method is not preserving default = namespace spec?

 

I've produced a simple test that tries to reproduce this, = and it works correctly for me. So we need to reproduce the circumstances under = which the failure occurs. Could you please try to put together a little = application that demonstrates the problem? It will also be necessary to know exactly = what software versions you are using.

 

There don't seem to be any known bugs in this area. However, = most of my testing (including the test mentioned above) has been with = XmlDocument instances generated directly by parsing source XML documents. Experience = with the Java product suggests that most of the problems with wrapping a DOM = come when the DOM is constructed programmatically. There are many different = ways of building a DOM, including many ways of creating structures that will = never be produced directly by the XML parser.

 

Regards,

Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay

 


From: Bill Cohagan = [mailto:cohagan@acm.org]
Sent: 09 October 2009 19:15
To: 'Mailing list for the SAXON XSLT and XQuery processor'
Subject: [saxon] Wrap() method is not preserving default = namespace spec?

I’m running saxonb9-1-0-5n and having = problems converting a System.Xml.XmlDocument -> XdmNode via the = DocumentBuilder.Wrap method. The code in question is:

 

           &= nbsp;      XdmNode inputXML =3D processor.NewDocumentBuilder().Wrap(input);

 

Examining the “input” (XmlDocument) = shows an XML doc with the following top level element:

 

<PRRRevisionRequest DatePosted=3D"2/4/2008 = 12:00:00 AM" Number=3D"754" Title=3D"Resource Settlement Due = To Forced Transmission Outage" IsDirty=3D"false" = IsNew=3D"false" Tombstone=3D"false" = xmlns=3D"gptg:PMSA:gptg.net">

 

Examining the inputXML XdmNode after the call to = Wrap shows an XdmNode with the following top level element:

 

<PRRRevisionRequest DatePosted=3D"2/4/2008 = 12:00:00 AM" Number=3D"754"

         &= nbsp;          Title=3D"Resource Settlement Due To Forced Transmission = Outage"

         &= nbsp;          IsDirty=3D"false"

         &= nbsp;          IsNew=3D"false"

         &= nbsp;          Tombstone=3D"false">

 

So, the question is, WHAT THE HECK HAPPENED TO THE = DEFAULT NAMESPACE SPEC? Obviously this is causing problems in the subsequent XSL transform processing…

 

Please advise,

 Bill

------=_NextPart_001_0017_01CA4A8F.E0C5D240--