You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The standard defines several "*ProductType" via distinct classes, and additionally has an enumType ("productFamilyType") with the list of possible product types.
"substanceType" uses the enumType to inform for which produc type a substance is allowed, but lacks a direct link to a "*ProductType" class.
The whole construct is needlessly complex and at the same time not robust enough to really link a "substanceType" to a product type.
I see two possible solutions:
refactor the distinct "*ProductType" classes into one single, unified "productType" class. This class will contain the product information plus a "family" attribute using the "productFamilyType" enumType to inform about the family of the product. The same list is used in the "substanceType", thus building an n..n relationship between "productType" and "substanceType" thanks to the "productFamilyType"
Keep the distinct "*ProductType" classes but remove the "productFamilyType" enumType completely. The reference in "substanceType" should be done via the ID of an instance of one of the "*ProductType" classes. The product family is derived directly from the class which is instantiated.
If I understand things correctly, option 1) is not really viable for at least one important and well-known BLW application (in development at the time of writing).
Up for discussion. In any case, this is a major change.
The standard defines several "*ProductType" via distinct classes, and additionally has an enumType ("productFamilyType") with the list of possible product types.
"substanceType" uses the enumType to inform for which produc type a substance is allowed, but lacks a direct link to a "*ProductType" class.
The whole construct is needlessly complex and at the same time not robust enough to really link a "substanceType" to a product type.
I see two possible solutions:
If I understand things correctly, option 1) is not really viable for at least one important and well-known BLW application (in development at the time of writing).
Up for discussion. In any case, this is a major change.
See also #42
The text was updated successfully, but these errors were encountered: