[OASIS Issue Tracker] Commented: (TOSCA-21) Issue 6: "id" vs "name"

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

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

Doug Davis  commented on TOSCA-21:
----------------------------------

Guessing that the problem being addresses is that it might not be clear
whether 'name' or 'id' should be considered to be unique, I would suggest that
we simply modify the text for those fields to fully explain this rather than
dropping one or the other.


To me the spec needs to make it clear that:
- id is unique across all resources and is mandatory
- name is optional and there are no unique constraints on its value.  This is strictly there for humans to use for whatever purpose they choose.  Tosca implementations should not really do anything with this value other than to persist it.  In other words, Tosca implementation should not count on it being present (since its optional), nor should they use it to uniquely identify a resource since they can not control what a user (human) might set its value to.  

This would be consistent with many other specifications and Cloud implementations.

So, I agree with Thomas with keeping it as is but I'd be ok with clarifying text if people think that would help.

But I may still not being understanding what the problem is that this issue is trying to address.


> Issue 6: "id" vs "name"
> -----------------------
>
>                 Key: TOSCA-21
>                 URL: http://tools.oasis-open.org/issues/browse/TOSCA-21
>             Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
>          Issue Type: Sub-task
>            Reporter: Tobias Kunze 
>            Assignee: Tobias Kunze 
>
> This issue actually has three possible solutions:
>    1. Keep "id" and drop "name" (or make it optional); same for XML and YAML
>    2. Keep "name" and drop "id" (or make it optional); same for XML and YAML
>    3. Adopt solution (1) for XML and (2) for YAML; define translation between formats
> Aspects to consider are, among potential others:
>    A. Uniqueness of identifiers
>    B. Scope of uniqueness: local to the template or global
>    C. Enforcement or validation of uniqueness
>    D. Familiarity of construct
>    E. Culture ("geeky" vs "user-friendly")
>    F. Likelihood of acceptance
>    G. Simplicity
> During our call on 2012-06-07, is seemed that
> i. There was consensus that (A) is required but (B) only at the local level; import of external identifiers can occur either namespaced or optimistically
> ii. There was consensus that (C) uniqueness must be enforced. However, there was disagreement on where it should be enforced. Derek suggested that implementations should make use of XML's enforcement of the uniqueness of the "id" attribute. I suggested that this could be trivially carried out by the implementation itself, quite possibly with better error messages. Some of the argument may have rested on (D) Familiarity of users with the XML "id" attribute.
> iii. There was a difference in (E) among the TC

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