Add XmlProcessor initial implementation

[marc-gr]

This PR creates a new XML processor that achieves feature parity with Logstash's XML filter.

⚙️ Configuration Options

processors:
  - xml:
      field: "xml_data"
      target_field: "parsed"
      to_lower: false
      # Logstash-compatible options
      xpath:
        "/root/item/@id": "item_id"
        "//product/name/text()": "product_name"
      namespaces:
        "ns": "http://example.com/namespace"
      force_array: true
      force_content: false
      remove_namespaces: false
      ignore_empty_value: true
      parse_options: "strict"

🏗️ Architecture

• Streaming SAX Parser: Optimal memory usage for large XML documents
• Selective DOM Building: Only builds DOM when XPath expressions are configured
• Pre-compiled XPath: XPath expressions compiled at processor creation for performance
• Security: Enhanced XXE protection with secure parser factory configurations

📚 Documentation

Documentation includes:

• Complete configuration reference
• XPath expression examples
• Namespace configuration guide

Logstash differences

• ignore_empty_value behaves a bit different than suppress_empty, but I think it matches better with other processors behavior. It could be adapted, or even add both, but I found it confusing.

Closes #97364

[github-actions]

🔍 Preview links for changed docs:

• docs/reference/enrich-processor/index.md
• docs/reference/enrich-processor/xml-processor.md

🔔 The preview site may take up to 3 minutes to finish building. These links will become live once it completes.

[elasticsearchmachine]

Pinging @elastic/es-data-management (Team:Data Management)

[elasticsearchmachine]

Hi @marc-gr, I've created a changelog YAML for you.

[github-actions]

🔍 Preview links for changed docs

• docs/reference/enrich-processor/xml-processor.md
• docs/reference/enrich-processor/index.md

[Copilot]

Pull Request Overview

Adds an initial implementation of a new XmlProcessor to parse XML input into JSON-like structures with feature parity to Logstash’s XML filter, alongside configuration options, factory validation, and documentation.

• Introduce XmlProcessor with streaming SAX parsing, optional DOM building for XPath, and secure defaults.
• Add end-to-end tests (XmlProcessorTests) and factory validation tests (XmlProcessorFactoryTests).
• Register the processor in the plugin, update module-info, documentation, and changelog.

Reviewed Changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
modules/ingest-common/src/main/java/org/elasticsearch/ingest/common/XmlProcessor.java	New XML parsing processor implementation
modules/ingest-common/src/test/java/org/elasticsearch/ingest/common/XmlProcessorTests.java	End-to-end tests for XML parsing behavior
modules/ingest-common/src/test/java/org/elasticsearch/ingest/common/XmlProcessorFactoryTests.java	Tests for factory config and validation
modules/ingest-common/src/main/java/org/elasticsearch/ingest/common/IngestCommonPlugin.java	Register XmlProcessor in the plugin registry
modules/ingest-common/src/main/java/module-info.java	Add requires java.xml for XML APIs
docs/reference/enrich-processor/xml-processor.md	Documentation for XML processor
docs/reference/enrich-processor/toc.yml	Add entry for xml-processor.md
docs/reference/enrich-processor/index.md	Include xml processor in the index
docs/changelog/130337.yaml	Changelog entry for PR

Comments suppressed due to low confidence (1)

docs/reference/enrich-processor/xml-processor.md:9

• The implementation actually uses a streaming SAX parser with optional DOM building for XPath. Update this description to reflect the streaming-based approach for accurate documentation.

Parses XML documents and converts them to JSON objects using a DOM parser. This processor efficiently handles XML data with a single-parse architecture that supports both structured output and XPath extraction for optimal performance.

[PeteGillinElastic]

Hi @marc-gr. First of all, thanks again for the contribution.

I figured that a sensible way to approach the review here is to cover the behaviour in a first round, and then cover the implementation later. Since you helpfully included comprehensive documentation, I figured that would be a good way into it. As such, in this review I've looked at those files, but I haven't looked at the actual Java code at all. I'll do that in a later round.

Overall, I think that the behaviour looks sensible, and the docs are nice and clear. I've left a few comments, which are mostly presentational, or asking for clarification.

[PeteGillinElastic]

Nit: It looks like the contents of this section are in alphabetical order. So can you move this after the trim processor below?

[PeteGillinElastic]

I'm still slightly unclear what this does. As shown in the previous section, it seems to include some #text keys without this option, but not all. Could you perhaps explain what the behaviour without this option is, and for your example maybe you could choose something which nicely illustrates the two behaviours (with and without this option) and show both for contrast?

[PeteGillinElastic]

For what it's worth, I was somewhat surprised at this is behaviour. The text and the tags are all there, but the information about how they are ordered and interleaved has been thrown away.

You're the one who has actual use-cases, and you know how logstash behaves, so if you tell me that this is a sensible thing to do then I'll believe you. I just wanted to check that it's deliberate.

[PeteGillinElastic]

Could we consider maybe calling this remove_empty_value? Or even remove_empty_values? It seems to me that this would make it seem logically related to remove_namespaces, rather than to ignore_missing and ignore_failure, which more accurately reflects what it does.

[PeteGillinElastic]

Is there a reason to make this a string-valued option where "strict" is the only valid value, rather than e.g. a boolean strict_parsing option?

[PeteGillinElastic]

Am I correct in figuring that target_field is ignored if this is set? I think it might be worth stating that explicitly.

[PeteGillinElastic]

Please forgive my ignorance, it's a long time since I've dealt with XML namespaces (or XML at all, to be honest!). Why do we need to include the namespace mappings in the processor definition, when — in this example, at least — the same mappings are provided via the xmlns:* attributes in the source document?

[PeteGillinElastic]

I sort of wonder whether this section adds much value, although I feel less strongly about this than about the lower case one.

[PeteGillinElastic]

Perhaps I'm just being blind here, but... I don't see any control character here?

[PeteGillinElastic]

Nit: This is going into the release notes, so we should phrase it in a more user-facing way. Something like "Add xml ingest processor for parsing XML", maybe.