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

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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

Tobias Kunze  edited comment on TOSCA-21 at 6/21/12 9:20 AM:
-------------------------------------------------------------

The original issue discussed on the call was that id and name are redundant. Both identify the entity in question. More precisely, id is superfluous (nobody needs it, i.e. it is entirely internal to the implementation) and name is what a human would want to use. The issue becomes very apparent if you consider declarations like

    - id: 4
      name: &proxy-server
      requires: "apache (>= 2)"
    - id: 5
      name: &php-server
      requires: "apache (>= 2.2.11, mpm-prefork)"

All I (as a human) ever care for is "name" so I can refer to it. "id" is superfluous and simply noise. 

None of the XML considerations matter if you consider filesystems: I don't want to have to name files by their inodes. I want to use filenames. The fact that the filesystem uses inodes internally may please the geek inside me, but is irrelevant to anything I want from the system.

I put it in such stark terms because I worry about user uptake. If the standard forces me to type out id's that have no utility to me, I won't use the standard. Our users don't come to TOSCA to see XML succeed but do get their stuff done with minimal effort.




      was (Author: tkunze):
    The original issue discussed on the call was that id and name are redundant. Both identify the entity in question. More precisely, id is superfluous (nobody needs it, i.e. it is entirely internal to the implementation) and name is what a human would want to use. The issue becomes very apparent if you consider declarations like

    - id: 4
      name: &proxy-server
      requires: "apache (>= 2)"
    - id: 5
      name: &php-server
      requires: "apache (>= 2.2.11, mpm-prefork)"

All I (as a human) ever care for is "name" so I can refer to it. "id" is superfluous and simply noise. 

None of the XML considerations matter if you consider filesystems: I don't want to have to name files by their inodes. I want to use filenames. The fact that the filesystem uses inodes internally may please the geek inside me, but is irrelevant to anything I want from the system.

I put it in such stark terms because I worry about user uptake. If the standard forces me to id's that have no utility to me, I won't use the standard. Our users don't come to TOSCA to see XML succeed but do get their stuff done with minimal effort.



  
> 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

        


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]