MESAInternational / B2MML-BatchML

B2MML is an XML implementation of the ANSI/ISA-95, Enterprise-Control System Integration, family of standards (ISA-95), known internationally as IEC/ISO 62264. B2MML consists of a set of XML schemas written using the World Wide Web Consortium's XML Schema language (XSD) that implement the data models in the ISA-95 standard.
Other
93 stars 45 forks source link

Unable to generate java classes with valid enumeration facets via xjc #58

Closed PierreREN closed 4 years ago

PierreREN commented 4 years ago

When generating java classes via xjc command of jaxb, the enumetation facets cannot be correctly inherite in the generated java classes. For example, the "EquipmentElementLevel1Type" extends "CodeType" and is designed to be an enumeration of all the valid values when describing the equipment element hierarchy level, as below:

However, the generated java class indicates no enumeration facets: @XmlAccessorType(XmlAccessType.FIELD) @XmlType(name = "EquipmentElementLevel1Type") @XmlSeeAlso({ EquipmentElementLevelType.class }) public class EquipmentElementLevel1Type extends CodeType { } How can the enumeration facets be executed in this case?
PierreREN commented 4 years ago

@JoeDo @racheliurui @BrentHumphreys @Emers @racheliurui Thanks so much for your explanation on the usage of CodeType as a unique tool for dealing with enumerations. This point has been confusing me a lot. Haven't understood the inspiration why you guys design such a type.

Dennis-Brandl commented 4 years ago

The type was used so that the "Other" type could have the additional element "OtherValue" to contain the string of the other value when the "Other" enumeration is used. This was the recommended method when these were built. If there is a better way (which is backward compatible), then we could use it. Any suggestions are welcome.

PierreREN commented 4 years ago

I have been seeking for alternative ways for the enumerative types, and it seems that I always prefer the simplest way, which is to use the enumeration classes directly without extending the CodeType class. The enumeration classes will explicate themselves when transferred, as the enumeration classes can be interpreted when defined as a simple type based on String. However, in my opinion, the most important idea of CodeType is to indicate not only the enumeration list but also other related information when transferring the data to another system. And other classess such as IdentifierType are of the same case. From this point, the current design seems quite reasonable and better ways (which is especially backward compatible) are not that obvious. I may let go this issue for now and keep thinking about other possibilities in the future. At the same time, to face my current concern, I tend to give up the usage of classes like IdentifierType or CodeType and drop part of the B2MML termilogies from my major project. The B2MML types will more likely to be used as the interfaces among systems, dealing with DTOs, rather than to be relied on as a basis for designing new MOM-related applications, dealing with domain entities. Perhaps that is more close to what you expect B2MML to be when first designed, is it?