Add IOpenXmlNamespacePrefixFeature to control written namespace prefixes

[jafin]

Summary

Elements are serialized with a built-in prefix for their namespace, so a worksheet is written as <x:worksheet xmlns:x="..."> where Office writes <worksheet xmlns="...">. Both are valid, but consumers that parse without a namespace manager are sensitive to the difference, and there was no way to choose.

This adds an opt-in feature registered on the package:

document.Features.SetNamespacePrefixOverride(
    OpenXmlNamespacePrefix.DefaultFor("http://schemas.openxmlformats.org/spreadsheetml/2006/main"));

OpenXmlNamespacePrefix.Create(Func<string, string?>) supports arbitrary prefixes per namespace. Output and OpenXmlElement.Prefix are unchanged when no feature is registered.

Resolves #90

Problem

Elements are serialized with a built-in prefix for their namespace, so the SDK writes

<x:worksheet xmlns:x="http://schemas.openxmlformats.org/spreadsheetml/2006/main">

where Office writes

<worksheet xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main">

Both are valid and Excel reads either. The difference matters to consumers that parse the XML without a namespace manager — XPath, regex, strict diffing — and there is currently no way to choose. Opening an Office-authored file and saving it also converts it to the prefixed form, because default-namespace declarations are discarded at parse time (OpenXmlElement.cs:1583).

Design

• The override is applied by an XmlWriter decorator wrapped around the part root rather than while resolving each element's prefix. A namespace-qualified attribute such as w:rsidR forces the underlying writer to declare the built-in prefix on its element, after which XmlWriter.LookupPrefix reports that prefix, so any decision taken from the writer's scope would silently revert the rest of the subtree. Forcing the prefix as each element is written keeps the whole tree consistent and covers unknown and extension elements.
• Every namespace the part uses is validated before the part stream is opened, so a rejected prefix leaves the previous part content intact. A prefix already bound to another namespace, by the built-in table or by a declaration in the document, is rejected with an InvalidOperationException naming both namespaces. Taking one would otherwise either be refused by the writer as a redefinition or silently rebind the other namespace to a generated prefix (r:id shipping as p3:id).
• Existing namespace declarations are preserved, so round-tripped documents keep what they declared and mc:Ignorable values are not stranded.
• Descendants written under the override reuse the namespace resolver the root resolved, instead of walking to the part root through the feature chain per element. The override path performs one tree walk per save, the same as the un-overridden path.
• The two internal XmlWriter decorators share a forwarding base class.

Scope and limits

Documented on IOpenXmlNamespacePrefixFeature: OpenXmlElement.Prefix is untouched so validation XPaths stay well formed; an unparsed part root is still copied verbatim; OpenXmlPartWriter and the LINQ-to-XML save path are unaffected.

Tests

33 tests in NamespacePrefixOverrideTests cover SpreadsheetML and WordprocessingML output, qualified attributes, unknown elements, declared and reserved prefixes, validation ordering, round-tripping, and the unchanged default behavior.

Performance

Saving a 50,000-row, 250,000-cell worksheet to memory, best of five runs, net10.0 Release:

Build	No override	With override	Overhead
Before patch	184 ms	242 ms	+58 ms
After patch	189 ms	211 ms	+22 ms

The remaining overhead is the decorator's per-element dispatch and the feature's prefix lookup.

[jafin]

@dotnet-policy-service agree