Remove namespace prefix from the XML Object

[saper]

Do not allow to specify the namespace prefix for the XML object. Only namespace URIs should be used to identify the namespaces used.

The prefix functions only as a placeholder and has a meaning exclusively in the context of the XML document

Namespaces in XML 1.0 (Third Edition)
https://www.w3.org/TR/REC-xml-names/#ns-qualnames

[saper]

I have submitted this for a 3.2.0 branch. But maybe, if there is a consensus, this should be backported to the older branches.

[handrews]

@saper Thanks for your efforts here. I'm afraid we cannot make backwards-incompatible changes such as removing a field in a minor release (3.1 was an exception made due to the pain caused by conflicting with the JSON Schema standard, and not an exception we want to repeat). This is something that can be taken into account in 4.0 a.k.a. Moonwalk. We have not yet gotten into how we plan to handle XML in that release.

[saper]

Thank you, that is what I initially thought we should not do, but I saw a couple of less obscure things removed and decided to file this. What about just adding the comment not to use this thing at all? If the attribute is present in the OAS, the tools SHOULD simply ignore it.

(I am still in search of the tooling that supports namespacing of the XML-Object but I could not find any, yet - pointers welcome).

[saper]

I do have a pretty obscure use case for this though. I have a commercial application (a proxy) that can handle both OpenAPI and SOAP requests.

As it turns out, the some low level HTTP errors (401, 404, 500, and others) do return a text/xml SOAP response, even if otherwise the API is defined using OAS and uses JSON.

So I have to tell the clients to expect, among application/json higher-level errors from the backend application, a text/xmlresponse with a SOAP Fault message it, that might come from the proxy.

It seems perfectly possible to model SOAP Fault using the XML Object feature; but the namespace prefix must be ignored, since in theory random prefixes can be returned (or automatically generated ones like ns1, ns2, ...).

[handrews]

@saper that use case is quite reasonable!

Having looked into this more deeply, I think there might not really be a problem here. The lack of tooling support for the XML Object (which you noted) makes it hard to say for certain in practical terms. I know it gets used, but it might be used more by custom tooling than major vendors. I'm really not sure.

Anyway....

The way the OAS documents the XML Object seems to mostly be about how to use it to serialize JSON values to XML. In that direction, it's perfectly valid to specify namespaces and prefixes.

The OAS does not explicitly state any parsing requirements or validation behavior. The most obvious reading is to require the prefixes to match. But the XML Object is described as "metadata" rather than validation. Arguably, the W3C's SHOULD directives here could be taken to mean "the prefix field is only used on serialization, and not on parsing, as the specific prefix used does not impact parsing."

[handrews]

To re-cap the conversation (but with an official "Request changes" status):

• We cannot remove prefix in a minor release
• The prefix field is actually necessary for correct serialization of JSON values into XML, and in that sense does not violate the W3C's "SHOULD" requirement any more than any other XML authoring tool that allows setting prefixes for namespaces
• However, the "SHOULD" does mean that, when parsing and validating, as long as the namespace field matches the namespace in use, a mismatch in prefix ought to be ignored as the OAS is, in a parsing context, an "application" (I think- are there XML parsing tools that enforce a specific prefix, and are they considered compliant wiht the W3C?)

No breaking changes in minor versions

[lornajane]

Discussed this topic in the TSC meeting and generally agreed that we do not support removing the prefix field. However a separate PR can be created to clarify that the prefix can be ignored when parsing.