XDocument/XmlWriter: Whitespace not preserved with `xml:space="preserve"` when writing with settings option `Indent = true`

[SetTrend]

Description

When saving an XDocument, whitespace is not preserved for XElement elements declared with xml:space="preserve".

Reproduction Steps

using System;
using System.Xml.Linq;

namespace WhitespaceTest
{
  internal class Program
  {
    static void Main()
    {
      XElement root;

      XDocument xDoc = new XDocument(
        root = new XElement("outer"
          )
        );

      root.Add(
        new XElement("middle",
          new XAttribute(XNamespace.Xml + "space", "preserve"),
          new XElement("inner"
            )
          )
        );

      Console.Write(xDoc.ToString(SaveOptions.OmitDuplicateNamespaces));
      Console.ReadKey(true);
    }
  }
}

Expected behavior

There should be no whitespace output between <middle> and </middle>, because <middle> is declared with xml:space="preserve" and there is no whitespace in the in-memory object tree.

<outer>
  <middle xml:space="preserve"><inner /></middle>
</outer>

Actual behavior

Whitespace is added between <middle/> and <middle/>:

<outer>
  <middle xml:space="preserve">
    <inner />
  </middle>
</outer>

Configuration

.NET 9.0

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-xml
See info in area-owners.md if you want to be subscribed.

[jeffhandley]

The space=preserve attribute is not respected the way you've illustrated and expected.

For output formatting like you're looking for, you need to use the SaveOptions.DisableFormatting flag on the elements where you don't want new lines or indentation.

[SetTrend]

@jeffhandley:

But that's not correct according to XML specification on White Space Handling:

signal an intention that in that element, white space should be preserved by applications

You cannot expect HTML or XAML content to be presented to users as a single line, just because the XmlWriter doesn't provide results as specified by the spec. This is particularly true for longer documents.

This is a bug, not an intended behaviour. Please re-open.

[SetTrend]

Please re-evaluate you decision to tag this issue as "intended". There's an upcoming accounting standard, based on XML, that's becoming a mandatory standard in the EU next year. It's called "XRechnung". It must be possible for programmers and testers to easily examine and evaluate XML documents of any kind and size. That's what the indented mode is made for.

[colejohnson66]

Per the spec, xml:space applies to an "XML processor", and a processor is defined as a reader.

An XML processor must always pass all characters in a document that are not markup through to the application.

[Definition: A software module called an XML processor is used to read XML documents and provide access to their content and structure.] [Definition: It is assumed that an XML processor is doing its work on behalf of another module, called the application.] This specification describes the required behavior of an XML processor in terms of how it must read XML data and the information it must provide to the application.

It is up to the authoring application/user to write their XML in a way that xml:space is useful. While it would be nice for dotnet to recognize this attribute, it is not a bug to not do so. As long as it reads XML with xml:space correctly, dotnet is conforming.

[SetTrend]

Well … So how would you then explain that XmlWriter is adding artificial white-space to elements having xml:space="preserve":

(The right panel is output by XmlWriter. Paragraph and Run elements are getting indented, although they shouldn't be, due to xml:space="preserve".)

[colejohnson66]

As I quoted, xml:space is only a directive for the "processor", which is the reader. The writer is under no obligation to listen to that attribute.

[SetTrend]

Maybe … But that doesn't qualify a compliant writer for creating unsolicited XML.

[colejohnson66]

As I said, the writer is operating fine. It does not need to listen to the attribute. If it's generating "unsolicited XML" that you don't like, that's a feature request, not a bug. I do think such a feature should exist, but, again, it's not a bug.

[SetTrend]

I refuse calling a request to provide correct output a "feature request".

However, let's not discuss that. Just let's suggest the Microsoft team to correct the output.

In the meantime, I wrote my own XmlWriter, providing the correct output I need.