Adding support for XML response expectation expressions

[basdijkstra]

Are there any plans to add support to Pact .Net for XML response body expectations similar to what is possible in PactJS like documented here: https://docs.pact.io/implementation_guides/javascript/docs/xml#support

?

[adamrodger]

There are no plans to do this at present, no. I'm not sure how the JS one works because the Pact Spec doesn't say anything about XML support either.

[basdijkstra]

Thanks, @adamrodger.

Matt pointed me to this, though: https://github.com/pact-foundation/pact-compatibility-suite/blob/d22d4667c0bda76d408676044cb33db834e7167e/features/V1/http_consumer.feature#L5C1-L16

There’s some scenarios around XML in there. I’m not 100% that means XML is a first class citizen in the Pact spec, though.

It is telling that there are only two bindings that claim to provide XML support (JS and JVM).

[mefellows]

There are no plans to do this at present, no. I'm not sure how the JS one works because the Pact Spec doesn't say anything about XML support either.

There are XML test cases in the spec: pact-foundation/pact-specification@362b15a

But, this is one of the grey areas where the compatibility suite augments the spec. The specification is more concerned about the serialisation of the pact file, and to an extent, agnostic to certain content-types and behaviours. As discussed in our strategy work earlier this year, the objective of the compatibility suite is to help clarify the behaviours that are either not described or ambiguous in the spec itself.

Let's leave this open as a feature request. I don't believe it would be a huge amount of work to add XML given the infrastructure already available to .NET. See https://github.com/pact-foundation/pact-js/tree/master/src/v3/xml for how JS implements it over the FFI.

[adamrodger]

The test cases may mention XML but it doesn't appear anywhere in the spec. I imagine that's why it doesn't have wider adoption, as the spec only ever mentions JSON (and kinda multipart form, but not really) as the supported body format. Obviously there are plugins that can add further ones, but those are implicitly out of spec.

XML is a more complicated format than JSON and so if we're supporting it properly in the spec then a few test case examples aren't really enough. For example:

• Should element references (idref attributes) be 'special' in matching rules so that they're followed to the referenced elements, or is the reference itself just checked to be the correct type? If you don't follow references then how can you properly match a document?
• If an attribute just happens to only contain numbers then does that match a Number matching rule? How could you tell in this element: <foo bar="42" />? What if that's a SHA that just happens to only contain numbers, but other instances may contain letters?

That's why XML really needs XML Schema along with it to properly validate it. Only in the most simple circumstances will it work like JSON does, and it will fall down very quickly if we say we support XML without specifying what happens with those semantics.

JSON doesn't have to worry about things like that. ECMA 404 (the JSON spec) only defines valid syntax without any semantics attached so matching rules are much more straightforward.