I've now raised a patch to fix it, but in the meantime (if you don't want to rebuild the product) all I can suggest is writing some kind of fixup routine that checks for each element whether the prefix/namespace of the element node corresponds to some namespace declaration attribute on this or a containing element, and adds it if not.
 

Regards,

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



From: Bill Cohagan [mailto:cohagan@acm.org]
Sent: 12 October 2009 14:51
To: 'Michael Kay'; 'Mailing list for the SAXON XSLT and XQuery processor'
Subject: RE: [saxon] Wrap() method is not preserving default namespace spec?

Michael

  Is there any sort of c# level workaround to avoid this problem while you’re basking in the glow of the newfound pain?

 

Bill J

 

PS – Thanks for the quick response.

 

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

 

It seems that when the DOM is created by the XML parser, there will always be an attribute corresponding to each namespace declaration, but when the DOM is created programmatically, namespaces associated with the element or attribute names are not necessarily explicit as attributes attached to the element. So when looking for in-scope namespaces, Saxon not only needs to look for attribute named xmlns or xmlns:*, but also at the namespace part of all containing elements, and perhaps their attributes as well. Painful.

 

I could solve this easily enough for the serialization use case by adding a NamespaceResolver to the serialization pipeline, which performs the namespace fixup operation. However, that wouldn't solve it for XPath functions like in-scope-prefixes().

 

The .NET code here is the same as the equivalent Java code, and it wouldn't surprise me to find there's a problem on the Java side too.

 

Michael Kay

Saxonica

 


From: Bill Cohagan [mailto:cohagan@acm.org]
Sent: 11 October 2009 22:28
To: 'Michael Kay'; 'Mailing list for the SAXON XSLT and XQuery processor'
Subject: RE: [saxon] Wrap() method is not preserving default namespace spec?

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:

 

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

 

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

 

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

                    Title="Resource Settlement Due To Forced Transmission Outage"

                    IsDirty="false"

                    IsNew="false"

                    Tombstone="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