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: [OASIS Issue Tracker] Updated: (CAMP-17) Figures should be redrawn


     [ http://tools.oasis-open.org/issues/browse/CAMP-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Rutt updated CAMP-17:
-------------------------

    Proposal: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/49137/CampIssue17-ModelChanges-r1.docx

> Figures should be redrawn
> -------------------------
>
>                 Key: CAMP-17
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-17
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Improvement
>          Components: Spec
>            Reporter: Anish Karmarkar
>            Assignee: Tom Rutt
>            Priority: Critical
>
> I think most figures need to be redrawn. Specifically (not necessarily complete):
> Figures 1-5
>     I find these very hard to parse and understand. Can't we use simple icons?
>     Most of the tiny print inside the boxes are impossible to read
>     Figure 2 talks about "Platform Elements"
>     Figure 4 & 5 talk about "Language-specific Package", what is that?
>     Figure 5 appears to have a wrong caption
> Figures 7-12
>     I keep stumbling over these diagrams and just don't find them helpful
>     Line labels are redundant
>     Resource fields are practically unnecessary
>     Layout is confusing, in particular as the reader moves from figure to figure and the layout changes
>     Suggest to work from the diagram I uploaded in comment 13 to issue 1014: http://ec2-67-202-61-56.compute-1.amazonaws.com/drupal/node/29#comment-73
>     Figure 8 mentions "Constraints"
>     Figure 8: not sure all edges make sense, e.g. Assembly to Requirements
>     Figure 9: I don't see why we need to talk about inheritance. Ditto for the "parameterization" arrow. A platform has platform components, each of which may expose a capability resource, that's all I think?
>     Figure 10: Again, I find the "parameterized" arrow confusing, particularly from PC3C to PC3R (which is wrong, but it looks like the diagram tries to say this, even though the tip seem to be attached to PC1R). Also, I'm not sure PCnC is actually parameterized from PCnT? Similarly, I don't understand why we need OO language instead of REST linking here.
> Figure 13
>     Remove "frozen" state
> Figure 16
>     Replace "Platform Application" with "Container" (not a technical term)?
> Figure 17
>     Dependency Resolution is from Requirement to Capability, not Requirement to Template as the figure suggests.
>     Suggest re-arranging the figure such that boxes run left to right as follows: Requirement -> Capability -> Template -> (Instance)
>     Suggest to drop the "parent" boxes (e.g. Platform Component Requirement) incl. the blue arrows since they don't add anything to the explanation (inheritance doesn't matter)
>     Incidentally, the text above the figure is wrong: "A Database Platform Component provides four ...". It only provides three resources. The Requirement resource comes from a different component.
> This issue was raised by Tobias Kunze and was drupal issue 1084. Note that the figure numbers may not correspond with what is in version 1.0.

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