Potentially incorrect default value for maxOccurs in XSD

[nerg4l]

In EBMLSchema.xsd the default value for maxOccurs is defined as 1.

The specification says the following about maxOccurs:

[...] If the maxOccurs attribute is not present, then there is no upper bound for the permitted number of occurrences of this EBML Element within its Parent Element or within the EBML Document, depending on whether or not the EBMLParentPath of the EBML Element is empty.

The semantic meaning of maxOccurs within an EBML Schema is analogous to the meaning of maxOccurs within an XML Schema; when it is not present, it's similar to xml:maxOccurs="unbounded" in an XML Schema.

In my opinion the XSD definition could be misleading. I propose to define maxOccurs as a union type or define 0 as a special value.

In case maxOccurs is defined as a union type:

• Schema change

  <xs:attribute name="maxOccurs" default="unbounded">
    <xs:simpleType>
      <xs:union> 
        <xs:simpleType> 
          <xs:restriction base="xs:integer">
            <xs:minInclusive value="0"/>
          </xs:restriction>
        </xs:simpleType> 
        <xs:simpleType> 
          <xs:restriction base="xs:string"> 
            <xs:enumeration value="unbounded"/> 
          </xs:restriction> 
        </xs:simpleType> 
      </xs:union>
    </xs:simpleType>
  </xs:attribute>

• This change would let maxOccurs behave almost the same as the attribute with the same name in XML Schema.

In case 0 is defined as a special value:

• Schema change

  <xs:attribute name="maxOccurs" default="0">
    <xs:simpleType>
      <xs:restriction base="xs:integer">
        <xs:minInclusive value="0"/>
      </xs:restriction>
    </xs:simpleType>
  </xs:attribute>

• The zero value has to be defined as a special value in the specification. From a logical perspective this could make sense because limiting the maximal occurrence to 0 is an invalid constraint.

[robUx4]

It does look like a bug indeed. I am not well versed in XSD but maybe @dericed knows more about this.

It does seem like it should have a default of unbounded and so the change would be your first proposal.

[dericed]

Yes a bug, the xsd says that if maxOccurs is not present then it implies maxOccurs="1", while the specification says that if maxOccurs is not present then it implies maxOccurs="unbounded". To be honest, I remember trying to define the element for storing "unbounded", but couldn't figure out how to make a non-negative-integer OR "unbounded" definition as @nerg4l has done.

As "unbounded" is common in XML Schemas, I prefer to use that rather than define 0 as a special case. The advantage of @nerg4l's first proposal is also that it would require a fix to the XSD but the rest of the specification is okay as is. @nerg4l would you mind submitting your first proposal as a PR?

[dericed]

@mcr, could you advise. @nerg4l identified a bug in Section 11.1.16. We haven't submitted an errata before, so could you share some guidance.

[nerg4l]

I will create a PR (you can expect it tomorrow afternoon CET). For this I checked the correct syntax for union types and I missed one xs:simpleType tag. The issue description was updated and now it contains that tag.

Also, I want to ask for some help in rewording Section 11.1.6.5 of the RFC. The PR will contain a draft but my English is quite broken.

[robUx4]

BTW that XSD is used to validate the Matroska Schema we are developping. So this fix is very welcome ! Thanks a lot.

[mcr]

Please bring the PR up to the mailing list. Errata can be submitted on https://www.rfc-editor.org/info/rfc8794 --- pointing to this issue with a short summary, such as four points above would be great. It will go to the AD, who will then bring it back to the list, and we'll agree that it is a "hold for next revision". This issue should probably be marked "errata-rfc8794" or some such label, and left open.