OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[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]