DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10009>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10009 indentation not working with Node.appendChild() [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From [EMAIL PROTECTED] 2004-02-18 17:21 ------- ===== THIS WAS POSTED TO [EMAIL PROTECTED] ON JUNE 24, 2002 =========== ===== BY Henry Zongaro ======================================================= Hi Pavani, Sorry I didn't follow up on this on xalan-j-users right away. I've read section 16.1 of XSLT 1.0 ("XML Output Method") [1] a little more carefully, and there's one passage that I'm a little concerned about; it reads as follows: [[ The xml output method should use an algorithm to output additional whitespace that ensures that the result if whitespace were to be stripped from the output using the process described in [3.4 Whitespace Stripping] with the set of \ whitespace-preserving elements consisting of just xsl:text would be the same when \ additional whitespace is output as when additional whitespace is not output. ]] If the resulting document (before the effect of indent and indent-amount) contained a fragment like the following, does the passage that I've quoted from 16.1 mean that no additional whitespace should be introduced before the xsl:text end-tag? If so, I believe the current behaviour of SerializerToXML would meet this requirement, but the change you're recommending would have to account for this case. Similarly, if xml:space attributes appeared with the value "preserve". <!-- There are several of blanks and line-feed characters between the following tags --> <xsl:text xmlns:xsl="http://www.w3.org/1999/XSL/Transform";> <xsl:text/> I'm also unsure whether the behaviour with your patch would be expected for a result like the following, where all blank lines between the tags contain only linefeed characters. <abc> xyz </abc> I believe your patch would strip out any linefeed characters that appeared in element content before any non-whitespace text, and leave alone any that came after, so producing the following result. <abc>xyz </abc> Thanks, Henry ======================================================================== I have this to add. The original input xml document was this <Inventory_Attributes> ..<Products> ....<Product name="my_product"> ......<Version>A</Version> ......<Version>B</Version> ......<Version>C</Version> ....</Product> ..</Products> </Inventory_Attributes> I've replaced the leading whitespace (spaces) in your document. Each group of leading whitespace characters (actually the new line character at the end of the previous line plus the leading whitespace characters) is effectively considered to be a <xsl:text> node and is significant. Your new element that you append to be a child of the <Product> node is inserted after the last child node of <Product> and the last child node is not <Version>C</Version> but the text node that is just before the closing </Product> tag. So you essentially have this in your DOM after the extra child is added: <Inventory_Attributes> ..<Products> ....<Product name="my_product"> ......<Version>A</Version> ......<Version>B</Version> ......<Version>C</Version> ....<Version>new_added_version</Version></Product> ..</Products> </Inventory_Attributes> During serialization an opening element tag or closing element tag will not be indented if a text node was serialized just before it, otherwise we are adding characters to an existing text node and changing it. The only opening or closing tag that has no text before it is the </Product> tag so the serializer is free to indent that one thing (I've put semicolons to indicate the spaces inserted due to indentation being on: <Inventory_Attributes> ..<Products> ....<Product name="my_product"> ......<Version>A</Version> ......<Version>B</Version> ......<Version>C</Version> ....<Version>new_added_version</Version> ;;;;</Product> ..</Products> </Inventory_Attributes> Xalan is working correctly. This is not a bug. Regards, Brian Minchau
