Formalize how to express null value in xml

[ahmednfwela]

Since XML has no concept of null, how can we handle validating a null value (both as an attribute and as an element) ?

consider the following 3.0 schema :

person:
  type: object
  required:
    - name
    - attrName
  properties:
    name:
      type: string
      nullable: true
    attrName:
      type: string
      nullable: true
      xml:
        attribute: true

notice how required here prevents us from removing the attribute/element

I have thought about this, and here are some of the approaches I came up with:

For elements

Approach 1: self closing tags

<person>
  <name />
</person>

Pros: Makes sense to whoever reads it
Cons: Nothing i can think of, but maybe some xml parsers can consider a self-closing tag equivalent to empty string and don't distinguish between them, which means they don't survive round tripping:
e.g.
<name /> gets represented on the way back to: <name></name>

Approach 2: empty string

<person>
  <name></name>
</person>

Cons: if the property is of type string, it's not possible to distinguish between a non-null empty string and a null.
Workaround: force strings to be wrapped around double quotes, e.g.

• this is null:

<name></name>

• this is empty string:

<name>""</name>

• this is valid string:

<name>"hello"</name>

• this is non valid string

<name>hello</name>

Ofc this workaround is very problematic and not good since most parsers consider "" A valid 2 character string.

Approach 3: special marker attribute

<name xsi:nil="true"></name>
<name xsi:nil="true"/>

Pros: Can represent nulls consistently without having to check the contents of the element, this is also how xml schema does it.
Cons: Size overhead of having to use xsi:nil="true" everywhere null is used.

For attributes

Approach 1: empty string

<person attrName="" />

Approach 2: disallow nullable attributes altogether

make it that xml.attribute: true and nullable: true are mutually exclusive

[ralfhandl]

@ahmednfwela Thanks for reporting this, and for the detailed research and references.

Preliminary analysis for elements

XML 1.0, section 3.1 "Start-Tags, End-Tags, and Empty-Element Tags" states that the element forms <name></name> and <name/> are equivalent and represent an element with no content, aka an empty element, so approaches 1 and 2 are equivalent.

The meaning of "empty" seems to depend on context/implementation; for string-valued elements "empty" means the empty string.

So approach 3 (xsi:nil="true") seems to be the way forward.

Preliminary analysis for attributes

XML 1.0, section 3.3.3 "Attribute-Value Normalization" describes an algorithm that MUST be applied before the value of an attribute is passed to the application or checked for validity. This algorithm begins with a normalized value consisting of the empty string, then appends to it. Thus attribute values are always strings, potentially the empty string, and never null.

So approach 2 (disallow nullable attributes) seems to be the way forward.

[handrews]

@ralfhandl For attributes, is there an Option 3: omit the attribute?

[handrews]

I am asking because due to compatibility reasons, we cannot forbid type: "null" on XML attributes in 3.x, so we need an alternative to recommend as a SHOULD. Mapping null to the empty string does not seem ideal.

[ahmednfwela]

@handrews How would this be distinguishable from required: false ?

[handrews]

@ahmednfwela in practice, it's probably not. But we can't do the preferred option of forbidding null for attributes in 3.2 because that would break compatibility with 3.1. (we don't want another incompatibility in a minor release after 3.0->3.1).

[ahmednfwela]

so we can say that for attributes setting nullable: true ignores the value of required.

[handrews]

@ahmednfwela we can't do anything that contradicts specified behavior in OAS 3.1.

[ahmednfwela]

@ralfhandl For attributes, is there an Option 3: omit the attribute?

@handrews but this is already contradicting OAS 3.1, as a schema with required: true + nullable: true would be invalid in 3.1 if the attribute was omitted

[handrews]

Hmm... I do see your point, @ahmednfwela . I'm kind of at the point of throwing my hands up on this and saying that if you try to use type: "null" on an attribute the results are implementation-defined. Which we need to do for both of these anyway for compatibility, but at least we can give a SHOULD for elements this way.