Mysterious "document must be well-formed" Failure
Replies (2)
RE: Mysterious "document must be well-formed" Failure [SOLVED]
-
Added by Eliot Kimber about 12 years ago
Found my user error: I wasn't actually including the module that had the templates that I wasn't seeing the messages from.
When I include it, the failure of course goes away.
That explains the failure: I was emitting text to the main output (which normally gets nothing).
However, that doesn't explain why I didn't get a failure in Oxygen. Something to do with how Oxygen configures Ant to run the transform perhaps?
I have asked Oxygen support that specific question.
Cheers,
Eliot
RE: Mysterious "document must be well-formed" Failure
-
Added by Michael Kay about 12 years ago
First, the issue with the evaluation license: I haven't worked out under what circumstances putting the license next to the JAR files succeeds/fails, but experience shows that it isn't 100% reliable. The only 100% reliable approach is to make sure that the directory containing the license file is on the class path.
Now the substantive issue.
You're right about the meaning of the message: it means a non-whitespace text node is being sent to the serializer before or after the root element of the result tree.
The most obvious explanation for oXygen not reporting the error is that it isn't using the Saxon serializer; we would have to ask oXygen to find out if that is the case.
I'm not sure you can deduce much about whether xsl:message output comes before or after the failure; order of processing can be very different from the source code order; and the location information for a serialization error is rather unreliable because of buffering. On the other hand if removing a line of code makes the problem go away, that is much stronger evidence (though still not 100% reliable; changing code in one area can affect the optimization applied to apparently unrelated code).
I would start by using "!standalone:omit" and "!doctype-system:" (nothing after the colon) on the command line. This should suppress the check that is failing, and produce serialized output which can then be checked for well-formedness. It should be easy enough to do the check visually, taking care of course that some non-whitespace characters are invisible, such as NBSP.
It might also be worth trying it with Saxon-B 9.1.0.8, just incase there's a known bug fixed after 9.1.0.5, though I think that's unlikely.
Another angle would be to capture the result of the offending apply-templates call in a variable, and examine its contents fairly carefully. Use as="item()*" on the xsl:variable declaration to prevent any document node being added. Use string-to-codepoints() to output any text nodes so we can see exactly what the text node contents are.
After that my next step would probably be to insert a tracing Receiver into the serialization pipeline, but unfortunately I think that requires a little Java coding - I can't see a way to switch it on from the command line, although the code is all there.
Michael Kay Saxonica
Please register to reply
.