xml property and root schemas

[MikeRalphson]

This is a question about the specification, and the intent of the following description in the Schema Object, relating to the xml property:

This MAY be used only on properties schemas. It has no effect on root schemas. Adds additional metadata to describe the XML representation of this property.

This has the effect of banning the construct

components:
  schemas:
    mySchema:
      type: object
      properties:
        a:
          type: string
      xml:
        name: xmlSchema

As a point-of-reference only, both swagger-ui and swagger-editor appear to honour this (useful) construct.

Is it possible to align the specification with real-world use for this case, and possibly move the restriction on xml properties on root schemas to those sub-properties (such as attribute and wrapped) where it seems to make sense?

[MikeRalphson]

This also raises the question: what is a "root schema"? The term is not defined elsewhere in the spec.

Given this fragment:

components:
  schemas:
    container:
      type: object
      properties:
        value:
          $ref: "#/components/schemas/value"
    value:
      type: object
      xml:
        name: errorValue
      properties:
        error:
         type: string

Is this allowed or prohibited (i.e. is value a "root schema")? Does value become a "root schema" if it is directly referenced (not from within a properties property?

[fmvilas]

Agree with @MikeRalphson. We can define the root schema as the first one "hanging" from a, for instance, Media Type Object schema property.

Given that schemas are reusable pieces, what is a root schema in one place will probably not be in another place. An example:

paths:
  /container:
    get:
      responses:
        '200':
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/container' # Here "value" is not root
  /value:
    get:
      responses:
        '200':
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/value' # Here "value" is root

components:
  schemas:
    container:
      type: object
      properties:
        value:
          $ref: "#/components/schemas/value"
    value:
      type: object
      xml:
        name: errorValue
      properties:
        error:
         type: string

So, from the schema perspective, there's no way to know if it will be root or not because there's no information about its context (and I think there should not be, to make them more reusable). This reminds me of the required property. It is defined in the parent schema because in some places it will be required and in some others, it will not.

components:
  schemas:
    container:
      type: object
      required:
        - somethingRequired
      properties:
        somethingRequired:
          type: string

[silkentrance]

I second that. The xml code generation hints must be available on the top level entities representing data types, and not just on the property level. Otherwise, one cannot customise the generated code.

And I would rather see this to be a part of the OAS 3.0.0 instead of some future release as it is currently being supported by Swagger 2.0 and we cannot migrate from that to OAS 3.0.0 without this feature.

And, according to the OP @MikeRalphson, OAS3 should differentiate between xml code generation hints on top level data types, items of arrayS and other properties.

Example

definitions:
  xml:
   type: object
   properties:
     name:
       type: string
     namespace:
       type: string
     prefix:
       type: string
  xmlOnProperty:
   allOf:
    - ./definitions/xml
    - type: object
       properties:
         attribute:
           type: boolean
           default: false
         wrapped:
           type: boolean
           default: false

[handrews]

@MikeRalphson JSON Schema 2019-09 has definitions for "schema document", "schema resource", "root schema", "schema object", and "subschema". It shouldn't be too hard to adapt that for the OAS situation of schema objects embedded in a non-schema document.

[hrennau]

It is helpful to be aware of the analogies between JSON Schema and XSD. What seems to be called here a "root schema" (if I understand the comments correctly) is named schemas, that is, the schemas contained by /components/schemas (V3) or /definitions (V2). They are equivalent to a named type definition in XSD. Such a type definition is used by element declarations or attribute declarations. The name of the item (corresponding to a JSON property name) is NEVER assigned by the type definition, always by the element/attribute declaration. These declarations are equivalent to the fields in a properties object. Like the name, also cardinality constraints can only be placed in those declarations, never in the types. Cardinality constraints are roughly equivalent to "required", @fmvilas - hence we only have to look at XSD and understand the equivalences in order to have a clear idea what belongs where. (Not that we could not do it differently, but we should think very carefully before doing it, and be aware of the deliberate deviation.)

And because of this analogy, it makes sense to me to keep the xml keyword out of "root schemas" = named schemas (alias type definitions): property naming is not the business of the type used to constrain the property value. Arguments in favor of allowing xml there in the interest of code generation should be reviewed crititically - they would have to be very convincing.

There is a real issue with translation into XML, which is the necessity to insert an XML root node, for which there is no correspondence in JSON. Currently, OAS foresees no possibility to control the invented name, leaving the integration developer in the lurch.