[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (CAMP-44) Clarify resource type issues and API
[ http://tools.oasis-open.org/issues/browse/CAMP-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=36223#action_36223 ]
Jacques Durand commented on CAMP-44:
-------------------------------------
About normative tags in the proposed normative text of Resource Type Inheritance section:
these 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).
So my suggestion would be, If we keep tagging such model-level statements, to use a special tag prefix, e.g. MOD-xx, and then we can explain why we don't write test assertions for these. And EX-03-04 should be considered as such "modeling" statements (MOD-nn).
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)."
> Clarify resource type issues and API
> -------------------------------------
>
> Key: CAMP-44
> URL: http://tools.oasis-open.org/issues/browse/CAMP-44
> Project: OASIS Cloud Application Management for Platforms (CAMP) TC
> Issue Type: Task
> Components: Spec
> Reporter: Alex Heneveld
> Priority: Minor
>
> There were several key questions about types that have come up in today's F2F:
> What type hierarchy will we use? Mark requests ability to define e.g. MyGreatDatabase which extends Database. (We could also have multiple inheritance / interface / etc.)
> How do we explore the type hierarchy? (The apidoc suggestion in CAMP-1 could come in here.)
> And do we permit dynamic attribute extensions -- e.g. a resource instance has values for other attributes not on its type? (Yes please!)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]