Saxon

Legacy ID: #4820598 Legacy Poster: Michael Kay (mhkay)

Saxon aims to be able to handle any DOM document that you throw at it: but that's not easy because there are so many minor variations between implementations. (Well, almost any: it has to be namespace-well-formed, and it has to be XML rather than HTML). We need to find out why this is failing. To start with, a stack trace that shows where the exception occurs. I'm slightly puzzled by your description - I don't think Saxon looks at the OuterXml property. It's going to be difficult to fix this without being able to reproduce it, which doesn't look as if it will be easy. Since you're already running it in a debugger, could I encourage you to probe a bit deeper and find out where the exception comes from? Incidentally, there are cases where you're better off rebuilding the DOM tree as a Saxon tree rather than wrapping it. That's because processing of a Saxon tree is so much faster than processing a DOM. To do that of course, you don't want to build a new DOM and wrap that, you can just give Saxon the lexical XML to work with (or you can force Saxon to copy the DOM to a Saxon tree, but it's possible that might fail in the same way).

Legacy ID: #4820909 Legacy Poster: Scott Colestock (scolestock)

Thanks much for your response - So, the exception occurs during the actual Run of the transform, but I suspect the problem occurs back at "XdmNode input = _processor.NewDocumentBuilder().Wrap(toTransform);" -- since after that statement executes, the contents of "input" don't loook good in the debugger. Interestingly, the following snippet works fine (where toTransform is an XmlDocument passed from BizTalk.) XdmNode input = _processor.NewDocumentBuilder().Build(toTransform.DocumentElement); xslt.InitialContextNode = input; DomDestination result = new DomDestination(); xslt.Run(result); Below is the stack trace from the transform method when the input is created via Wrap: " at net.sf.saxon.dotnet.NodeWrapper.makeWrapper(XmlNode node, DocumentWrapper docWrapper, NodeWrapper parent, Int32 index)\r\n at net.sf.saxon.dotnet.NodeWrapper.ChildEnumeration..ctor(NodeWrapper , NodeWrapper start, Boolean downwards, Boolean forwards)\r\n at net.sf.saxon.dotnet.NodeWrapper.iterateAxis(Byte axisNumber)\r\n at net.sf.saxon.dotnet.NodeWrapper.iterateAxis(Byte axisNumber, NodeTest nodeTest)\r\n at net.sf.saxon.expr.AxisExpression.iterate(XPathContext context)\r\n at net.sf.saxon.instruct.SimpleContentConstructor.evaluateItem(XPathContext context)\r\n at net.sf.saxon.instruct.ValueOf.processLeavingTail(XPathContext context)\r\n at net.sf.saxon.instruct.Instruction.process(XPathContext context)\r\n at net.sf.saxon.instruct.ElementCreator.processLeavingTail(XPathContext context)\r\n at net.sf.saxon.instruct.Block.processLeavingTail(XPathContext context)\r\n at net.sf.saxon.instruct.Instruction.process(XPathContext context)\r\n at net.sf.saxon.instruct.ElementCreator.processLeavingTail(XPathContext context)\r\n at net.sf.saxon.instruct.Template.applyLeavingTail(XPathContext context, Rule rule)\r\n at net.sf.saxon.instruct.ApplyTemplates.applyTemplates(SequenceIterator iterator, Mode mode, ParameterSet parameters, ParameterSet tunnelParameters, XPathContextMajor context, Boolean backwardsCompatible, Int32 locationId)\r\n at net.sf.saxon.Controller.transformDocument(NodeInfo startNode, Result result)\r\n at Saxon.Api.XsltTransformer.Run(XmlDestination destination)\r\n at BizTalkXsltDemo.Components.XmlUtility.ApplyTransformWithSaxonB(XmlDocument toTransform, String xslFileName)\r\n at BizTalkXsltDemo.Orchestrations.Demo.segment1(StopConditions stopOn)\r\n at Microsoft.XLANGs.Core.SegmentScheduler.RunASegment(Segment s, StopConditions stopCond, Exception& exp)"

Legacy ID: #4820916 Legacy Poster: Scott Colestock (scolestock)

(Oh, and the exception type itself is something along the lines of unexpected whitespace)

Legacy ID: #4821990 Legacy Poster: Michael Kay (mhkay)

It seems that the wrapNode() method has encountered a node type that it doesn't recognize, and from your second message it seems that this is a Whitespace node. I guess these haven't cropped up before because you don't normally get them when parsing lexical XML with default parsing options. Coding a patch looks easy; testing it less so! I'll probably put the fix in the next maintenance build (which is becoming necessary) with only regression testing.

Legacy ID: #4822715 Legacy Poster: Scott Colestock (scolestock)

Just for reference (and perhaps to assist testing), here is "OuterXml" on the XmlDocument that BizTalk is passing: OuterXml"<?xml version=&quot;1.0&quot; encoding=&quot;utf-8&quot;?>\r\n<MySourceData>foo</MySourceData>"