measurementType idea up for discussion

[AFoletti]

Idea

This idea came to me while looking at the 0262 standard and the implementation that this standard makes of unitType as defined in 0261. Looking forward to your reactions.

https://github.com/blw-ofag-ufag/eCH-0261/blob/42afd75319596921d8ec9265413ff2fe6f8f5909/src/eCH-0261-1-0.xsd#L467 At the moment, the unitType is only an enumeration of valid units. This forces any standard using it to build a 3-elements construct with quantity, unit and unitName (see picture from the 0262 word)

My proposal is to integrate those elements directly in the 0261 standard by renaming unitType to measureType (or similar) and then refactor this new measureType to contain:

1. a first "quantity" element as token or decimal (mandatory)
2. a second "unit" element with today's unitType enumeration (mandatory)
3. a third "unitName" element with the same goal as what is today defined in 0262 (see picture above) (optional)

Possible benefits:

• Downstream standards can define measures as a single type:measureType element. This will replace both the usecase of the picture above (one single element instead of 3) and the one in the picture below here (a measure with the unit in the element name, which makes it harder to handle m2m)
• clearer naming demarcation of this element from all the others "unitType" elements already present in the standard (e.g. "legalUnitType" or "localUnitType")

Possible issues:

• I am actually not sure that you can limit downstream the available unitType. For example, if I want to define a volume in m3 element, can I define my element in the downstream standard in such a way that uses type:measureType but only allows for unitType="m3"? --> confirmed not an issue, see comments below
• does it make the standard too restrictive?

A thought on interoperability and "unitName"

Using the "unitName" attribute as a free text is actually a blow to interoperability, since I (italian-speaking Ticinese) will write down "Pianta" or "germoglio" or whatever, which will of course not be the same as a german-speaking person using exactly the same unit ("plant"). I thus ask myself if it would not be better to get rid of this potential source of confusion and the "pc" unit and replace them with explicitly defined "pieces" like "plant", "box" or whatever is needed. I am fully aware of the potential complexity of the task, but since one of our goals is to allow interoperability I think it would be good to spend some time to think about this. One of the possible implications of such a change is that the whole CodeList must be made much more flexible to allow for easier integration of new "pieces" types. In this case, it could be necessary to make it an external list published in I14Y instead of an embedded one.

[montanajava]

The issue was discussed today with BLW personnel and technical consultants. We agree that the measureType is a good idea. Initial reflection seems however to indicate that the proper place for this is in the respective standard. Otherwise a restriction on allowable units is not possible. Putting a measurement of type measurement in the respective spec has the advantage that we can simplify attribute naming, e.g., heightInM would not be simply be height of type measurementType in which we can specify the unit from an allowable subset of unitTypes from eCH-0261. A secondary question of whether to pursue this change at this time or in a respective version 2 will be discussed with highter-level BLW representatives.

[AFoletti]

With all the power and flexibility of XSD, I guessed that restriction inheritance should not be an issue, so I looked a little further into it.

Apparently, you can solve both suggested usecases in a pretty elegant way:

1. When you have a measure only allowing a single unit (for example volume, which always needs to be in cubic meters) you can use "fixed" <xs:element name="unit" type="xs:token" fixed="m3"/> See this reference

2. When defining a measure allowing only for a subset of the globally defined units, you can simply redefine the element with a new restriction.

  <!-- Define the base complexType with the enumeration -->
  <xs:complexType name="baseType">
    <xs:sequence>
      <xs:element name="first" type="xs:string"/>
      <xs:element name="second" type="xs:string"/>
      <xs:element name="third">
        <xs:simpleType>
          <xs:restriction base="xs:string">
            <xs:enumeration value="a"/>
            <xs:enumeration value="b"/>
            <xs:enumeration value="c"/>
            <xs:enumeration value="d"/>
          </xs:restriction>
        </xs:simpleType>
      </xs:element>
    </xs:sequence>
  </xs:complexType>

  <!-- Define the downstream complexType by extending the baseType -->
  <xs:complexType name="downstream">
    <xs:complexContent>
      <xs:extension base="baseType">
        <xs:sequence>
          <!-- Override the third element with a smaller enumeration -->
          <xs:element name="third">
            <xs:simpleType>
              <xs:restriction base="xs:string">
                <xs:enumeration value="a"/>
                <xs:enumeration value="c"/>
              </xs:restriction>
            </xs:simpleType>
          </xs:element>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

</xs:schema>

So, apparently (this however needs careful validation by someone having proper XML tools at disposal...) the technical doubts around this proposal are solved and a measureType type could be safely defined in the 0261 standard to be reused in all the downstream ones. The open question remains when to implement this change.

[AFoletti]

I just noticed that case 2 from above (further restrict the available units in a downstream standard) is actually already used. See for example this snippet from 0263:

<xs:element name="transactionUnit">
    <xs:annotation>
        <xs:documentation xml:lang="de">Einheit, welche bei Transaktionen dieses Pflanzenschutzmittels verwendet wird. </xs:documentation>
    </xs:annotation>
    <xs:simpleType>
        <xs:restriction base="eCH-0261:unitType">
            <xs:enumeration value="kg"/>
            <xs:enumeration value="l"/>
            <xs:enumeration value="pc"/>
        </xs:restriction>
    </xs:simpleType>
</xs:element>

[AFoletti]

Added "A thought on interoperability" section to the initial post

[montanajava]

In QA meetings on 2023-01-22, it was decided to implement this in v1. Naming suggestion:

measureType with two elements/attributes named value and unit respectively.

value would be of type decimal with a relatively generous precision, say 4 spaces. unit is of type UnitTyp.

[lars-steffen]

Should we also include an optional "unitName" for specifing the name in case the unit is "piece"?

[montanajava]

. Should we also include an optional "unitName" for specifing the name in case the unit is "piece"?

Yes, I agree, and in the annotation specify how this is intended to be used.

[lars-steffen]

implemented with #22 at the moment, there is no restriction on the number of digits. I suggest to leave this open an put restrictions in place where needed.

[lars-steffen]

It seems to me, that restrictions in complexTypes don't work if the original Type is in a different namespace, this would mean, that we would need to redefine the measureType in any standard...

[AFoletti]

It seems to me, that restrictions in complexTypes don't work if the original Type is in a different namespace, this would mean, that we would need to redefine the measureType in any standard...

Ouch. Not good. But is the restriction not on the simpleType, actually? The base Type is complex, but that's the measureType, while the unit is a simpleType within it as enumerated. The restriction is only on this second element, no? I am honestly shooting in the dark here... this is outside my XML knowledge

[lars-steffen]

it works with redefining the measurementType in each namespace. This is the way I have implemented it in v1.