XML mapping for enum elements

[Zash]

Use case is XML where one of several states are indicated via presence of one of several possible elements, so that the name of the element is the relevant value. Examples from XMPP include chat states (e.g 'is typing', 'stopped typing' states), or the extensive list of error conditions.

Given this schema:

type: object
xml:
  name: wrap
properties:
  state:
    type: string
    enum:
    - foo
    - bar
    - baz
    xml:
      x_attribute_is_value: true # WIP name

this data:

{"state":"bar"}

would map to:

<wrap>
  <bar/>
</wrap>

When applied to a boolean property this could be used to map true to the element being present and false|null to it being absent.

[MikeRalphson]

I think your example has enum and state in the reversed positions? I'm not totally sure of the general usefulness of your proposed attributeIsValue property... Couldn't you just do:

type: object
xml:
  name: wrap
oneOf:
  - properties:
      foo:
        type: string
        minLength: 0
  - properties:
      bar:
         type: string
        minLength: 0
  - properties:
      baz:
        type: string
        minLength: 0

unless you had a need for a JSON representation of the same schema to actually use a an enum?

[Zash]

Thanks, I fixed the mistake. In turn, did you mean s/minLength/maxLength/ ?

Well, "need" is such a strong word, but I'd really like to enable a convenient and friendly data mapping of an XML-native system for those who may be more familiar with JSON.

You're right in that your example pretty closely mirrors what the native native XML schema usually look like for the things I have in mind, something like:

<xs:schema>
  <xs:choice>
    <xs:element name='foo' ref='empty'/>
    <xs:element name='bar' ref='empty'/>
    <xs:element name='baz' ref='empty'/>
  </xs:choice>
  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>
    </xs:restriction>
  </xs:simpleType>
</xs:schema>

Tho I'm thinking having (excuse the pseudo-bnf-json-ish syntax)

{"x": "foo" | "bar" | "baz" }

instead of

{"foo":""} | {"bar":""} | {"baz":""}

is closer to what I think the abstract data type is meant to be, and more convenient here.

[handrews]

What, if anything, needs to be done here in the spec? It seems like the basic use case has been answered, but there is something about booleans? Is there a requested spec change for that?

[github-actions]

This issue has been labeled with No recent activity because there has been no recent activity. It will be closed if no further activity occurs within 28 days. Please re-open this issue or open a new one after this delay if you need to.

[handrews]

@Zash I see that you marked the "no recent activity" bot comment with a thumbs-down. If there's something here you think needs doing, please just say what it is (because I can't figure it out from the "pseudo-BNF" bit and I'm triaging issues for the next set of releases). The activity counter is just so we don't have to keep poking old issues that no one cares about enough to respond to.

[Zash]

Just expressing general disapproval of such bots.

It was not clear to me that you wanted feedback from me because I am used to 'author' in contexts like this referring to those writing the specification itself.

I still find it awkward to express something that semantically is an enum where the value lives in the name of an XML element. I work on tooling that understands a flag for handling that and thought it could be worth considering at the spec level.

Feel free to close the issue.

[handrews]

@Zash I'm happy to throw things into the TODO pile. The problem is more that I'm not quite sure how to evaluate what your asking for, or how to fit it into the XML Object which is... probably not the most thoroughly-thought-through aspect of the OAS. But we've discussed making XML-related improvements in 3.2.

The other problem is that OpenAPI wants to be out of the business of adding extensions to JSON Schema. We'll keep the XML Object, but for some things (like how JSON Schema represents enums and related structures), it's really a JSON Schema question rather than one we can answer.

Please keep in mind that back in December we had well over 600 open issues, many of which had not been touched in years. This is why you're getting answers from people (me) who aren't experts in the area of the issue and might need a little help figuring out what to do.

The bots were a way to give people who opened old issues a good amount of time to respond without us losing track of what can be closed due to lack of response. Those labels only get added to issues we don't actually want to close but can't figure out how to resolve. I know a lot of repos just automatically label issues as stale and close them no matter what, but we don't do that here. We have the opposite problem.

We're now down under 250 issues, and likely to be under 200 once the 3.0.4 and 3.1.1 patch releases ship. Which has been a monumental undertaking. I hope you can see how the bots are helping us work through this rather than just auto-closing everything that's old. We're getting this project going again after several years of being in semi-hibernation and it's a lot of work.

You're welcome to close this if it's not worth the effort. I can't guarantee that we'll take action on it. But we're at least considering what our XML support road map looks like right now.