[OASIS Issue Tracker] Commented: (TOSCA-20) Spec issues identified in creating Service Template in YAML for More Complicated PHP Use Case.

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/TOSCA-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=30583#action_30583 ] 

Thomas Spatzier  commented on TOSCA-20:
---------------------------------------

Some more comments and maybe clarifying words on some of the issues:

Re 1:
Component is some re-usable, well, component. The item of re-use in TOSCA is a NodeType, so I would want to suggest to stick with the elements available.
NodeTypes can contain DeploymentArtifacts, so for things to be installed into Nodes we should use DeploymentArtifacts.
If some component (i.e. Node) is to be modeled as contained within a Node, this would be modeled as a NodeTemplate A (of NodeType a) related to a NodeTemplate B (of NodeType b) via a containment relation (RelationshipTemplate of RelationshipType "contains").
Summary: would suggest to see if existing TOSCA concepts are sufficient (which I think they are in this case) instead of defining new elements.

Re 6:
The id attribute of NodeTypes is required, since the fully-qualified name (QName) of a NodeType is built using its id and the targetNamespace in which the NodeType is defined. This allows for forming globally unique identifiers of NodeTypes. The name attribute of NodeTypes, which is optional, is more for human-readable names.
Note that the id attribute can still contain readable string.

Re 8:
The NodeTypeProperties element is not meant to provide values for a Node. It is rather meant to provide the schema for a Node's properties by means of an XML schema simple or complex type (the type attribute) or an XML schema element (the element attribute) - see wd06 line 532. A NodeTemplate (according to a NodeType) can then provide values for properties by specifying an XML document according to the schema defined at NodeType level - see wd06 line 948.
Therefore, I think the capability to provide name, type and value for properties is covered by the current spec.
Looking at the spec, it could be that the text is not explicit enough to convey this idea, so we could argue to enhance the spec text to make the usage pattern clear.

Re 9:
The naming scheme is to use camel-case for all element names and lower-case first character for attribute names. This is a common scheme for XML-based standards.

> Spec issues identified in creating Service Template in YAML for More Complicated PHP Use Case.
> ----------------------------------------------------------------------------------------------
>
>                 Key: TOSCA-20
>                 URL: http://tools.oasis-open.org/issues/browse/TOSCA-20
>             Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
>          Issue Type: Improvement
>          Components: Spec
>    Affects Versions: CSD03
>            Reporter: Paul Lipton 
>            Assignee: Tobias Kunze 
>             Fix For: CSD03
>
>
> These issues identified in document from Tobias. Decisions taken in meeting of 6/7. 

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