[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: issue #44, some wording for example
Regarding how to re-frame the Example as a modeler design issue (as opposed to something that would be an “error” case): “For example, it is not possible to define a resource type inheriting from both type A and type B, where A contains an attribute “address” that is constrained to only be an IP v4 address , and B also contains an attribute “address” that is constrained to only contain MAC addresses. Because the constraints stated for these two “address” attributes are not compatible, inheritance from both A and B is not possible (NOTE: even if some particular address value could qualify for both “address” types and constraints – e.g. here MAC or IPv4 -, clearly the composition of these constraints is not semantically meaningful).” And also, the normative tags in the proposed normative text of Resource Type Inheritance section are typically not possible to test on a “run-time”– are more about design rules for a model designer. So we could remove these tags. Although you could claim we already have a few hardly testable tags on “modeling statements” (some EX-nn, especially EX-03, EX-04). If we keep tagging such model-level statements, we should at least use a special tag prefix, e.g. MOD-xx, and then we can explain why we don’t write test assertions for these. -jacques |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]