The number of `enumeratedValue` elements in the `enumeratedValues` element if the `derivedFrom` attribute is present about cmsis_5

[jkrech]

This looks like a bug in the schema. The enumeratedValue minOccurs should be 0, even if this only true in case the derivedFrom attribute is specified.

[AndreySmirnov81]

If I understand correctly, XSD does not allow us to specify the relationship between the presence of the derivedFrom attribute and the number of enumeratedValue elements.
Do I understand correctly that if the derivedFrom attribute is missing, then the number of enumeratedValue elements should be at least one?

[JonatanAntoni]

[..] XSD does not allow us to specify the relationship [..]

No, not directly. What might work is grouping elements into exclusive groups. But that easily creates new issues/drawbacks.

The schema describes the syntax of a language. The relationship between elements is about semantics.

[AndreySmirnov81]

@JonatanAntoni
Could you give an example of how this can be done?

[jkrech]

It looks like the feature of reusing enumerated values has not really been used, as it would fail with the current schema. Sorry for the inconvenience.
Here is an example of how deriving an enumeratedValues description in a separate field.
I am using the ARM_Example.svd included in the ARM.CMSIS.5.9.0.pack in the CMSIS/utilities/ directory.
I am reusing the enumeration of the field "EN". To reference the enumeratedValues section, I need to specify the optional name tag in line 115

              <enumeratedValues>
			    <name>EN_enum</name>

For demonstration purposes I am adding a new register description:

        <register>
          <name>InheritEnum</name>
          <description>Control Register</description>
          <addressOffset>0xF0</addressOffset>
          <size>32</size>
          <access>read-write</access>
          <resetValue>0x00000000</resetValue>
          <resetMask>0xFFFFFFFF</resetMask>
          <fields>
	    <field>
	      <name>EN</name>
              <description>Enable</description>
              <bitRange>[0:0]</bitRange>
              <access>read-write</access>
              <enumeratedValues derivedFrom="TIMER0.CR.EN.EN_enum"/>
	   </field>
        </fields>
    </register>

In the above case it would have been smarter to derive the field EN.
The converter happily converts the above, however the schema requires changes to pass:
a) the derivedFrom attribute does not support dots . which are required for referencing a peripheral.register.field.enum. A new type shall be added to the schema e.g. referenceIdentifierType
b) as suggested above in the enumerationType the attribute minOccurs=0 nees to be set for the enumeratedValue element.

As a consequence the schema check no longer detects the case where the element enumeratedValues which is not derivedFrom another named enumeratedValues description, does not contain any enumeratedValue child elements.

Note that most people are generating the SVD file from some other source and therefore do not make use of deriving field and enumeration descriptions. I would be interested to understand how your use case is different.

[AndreySmirnov81]

@jkrech

Note that most people are generating the SVD file from some other source and therefore do not make use of deriving field and enumeration descriptions. I would be interested to understand how your use case is different.

I'm taking SVD from the project https://github.com/stm32-rs/stm32-rs (more specifically https://stm32-rs.github.io/stm32-rs/) in order to use it in https://marketplace.visualstudio.com/items?itemName=mcu-debug.peripheral-viewer.
Sometimes I open SVD in VS Code editor to view and make changes.
In VS Code I use the extension https://marketplace.visualstudio.com/items?itemName=redhat.vscode-xml.
This extension performs XSD validation, as a result of which many errors are detected (see the very first message).