Closed PierreREN closed 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.
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.
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?
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: