Saxon

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

What is the setting of xsl:output? If you don't have an xsl:output element, you might find that setting xsl:output method="xml" helps. When the output method is unknown, serializing content that appears before the first start tag is special-cased because the processor doesn't yet know whether it's going to use an XML or an HTML serializer. However, even with an explicit xsl:output I don't think you can rely on whitespace preservation here. The InfoSet doesn't allow a document node to have text node children, and the general consensus seems to be that whitespace between the children of the document node (like whitespace between atttributes within a start tag) is insignificant and therefore no processor is obliged to maintain it. The only caveat to this is that XML serialization allows for the possibility of generating an external general parsed entity rather than a well-formed document, and in an EGPE top-level whitespace is significant, I think. Michael Kay

Legacy ID: #3144461 Legacy Poster: DD (ddevienne)

Here are my only (top-level) declarations: <xsl:output method="xml" encoding="UTF-8" indent="yes" saxon:indent-spaces="2" /> <xsl:preserve-space elements="*" /> So it seems that I'll have to stick to my work around. Note that I find it annoying that one cannot fully preserve the syntax of an XML document thru an XSL step. For example, I have an XSL that transforms generic XML to HTML (with CSS-driven syntax coloring), and I loose the formatting or ordering of the attributes, which make the HTML document a lot less readable. For example, Ant elements can have many attributes, or some attributes are more important (thus before) than otehrs. But this is a moot point... Thanks again for the quick answer. --DD

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

When indent="yes" is set, the processor has a free hand to expand or contract whitespace text nodes as it sees fit. There's been another recent report that Saxon's handling of comments when indenting is unattractive and it's something on my list to look at, though not with high priority. I know what you mean about not liking having your attributes rearranged in arbitrary order. In fact, I think Saxon generally leaves the order intact - if they're reordered, that's probably down to the XML parser. Michael Kay

Legacy ID: #3144549 Legacy Poster: DD (ddevienne)

I know that report, it's my sole other one. I guess I like my whitespace ;-) I should invest time to learn xmlformat (or rewrite in Java/Ant if I knew how) to postprocess the files. I like XSL 2.0 + Saxon so much that I decided to report anything suspect I find to make it even better. Beside these white-space edge cases, it's always doing what I want it to do ;-))) --DD PS: BTW, is another edition of your XLS 2.0 books in the works that fixes the headings/tabs to be a better reference manual? It's not as convenient as the previous edition unfortunately.

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

>is another edition of your XLS 2.0 books in the works that fixes the headings/tabs to be a better reference manual? As you can probably imagine, I was pretty upset when I saw the page proofs for this and was told it was too late to change the headings. I want to do a revised edition when we have a final set of W3C Recommendations (still a year away, I fear) but it's obviously a commercial decision by the publishers. XML book sales have gone down considerably since the early days.