[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (TOSCA-7) Alternative Encodings of TOSCA Service Templates
[ http://tools.oasis-open.org/issues/browse/TOSCA-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=34094#action_34094 ]
Frank Leymann commented on TOSCA-7:
------------------------------------
@Derek, just for clarification:
ad (1): I assume that TOSCA will continue to maintain the XSD. In fact, this XSD will be the master representation of our metamodel, correct? If the latter is the case, I am not sure why we need to translate from YAML/JSON back to XML - sure, an implementation may choose to support YAML/JSON by such a translation, but this is an implementation choice, not a need for the spec. Final remark: as far as I understang YAML and JSON, their are not equivalent, i.e. a lossless back and forth translation is in general not possible (at least not without a couple of conventions).
ad (2): What semantics do you have in mind that needs to be expressed in YAML/JSON? The operational semantics of TOSCA is expressed today in text of the spec, except for some syntactic constraints that are encoded based on XSD features (e.g. cardinalities). From what you write, you seem to argue for subsetting TOSCA features in the sense of particular profiles. Especially, we can define simple profiles that support topologies that are defined by means YAML/JSON-based languages found elsewhere in the cloud community today. Did I get you right?
ad (3): I don't understand. Isn't this the "profile approach" I sketched above? If a profile is simple enough a modeler can use a text editor to specify his model without a graphical editor (which is not only true for YAML or JSON but also for XML).
> Alternative Encodings of TOSCA Service Templates
> ------------------------------------------------
>
> Key: TOSCA-7
> URL: http://tools.oasis-open.org/issues/browse/TOSCA-7
> Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
> Issue Type: Improvement
> Components: Spec
> Affects Versions: V1.1_CSD01
> Reporter: Derek Palma
> Assignee: Krishna Raman
> Fix For: V1.1_CSD01
>
>
> At the last (Jan 26) TC meeting there was some discussion about Alternative Encodings of TOSCA Service Templates. It may be useful to augment the draft to explicitly address this issue so it is clear that TOSCA is not confining itself to only XML encodings.
> Below is some text which captures some of these ideas:
> Alternative Encodings of TOSCA Service Templates
> The Topology and Specification for Cloud Applications (TOSCA) is a metamodel which specifies the core concepts, entities, relations and constraints required for defining IT services. This metamodel is encoded in this specification using XML Schema and related standards. Service Templates are instances of entities compliant with the TOSCA metamodel endcoded in XML following the syntactic rules governed by XML Schema and XML Specification.
> In order to further applicability and facilitate adoption, the TOSCA TC acknowledges the diversity of clouds, offering a diversity of languages and frameworks, with their respective user bases, and anticipates the need to represent Service Templates in encodings other than XML (e.g. YAML, JSON) as well as the need for API implementations in multiple languages that can create and manipulate Service Templates serializing to/from these alternative encodings. Implementations of alternative encodings should adhere to the TOSCA semantics in order to consume/produce semantically valid Service Templates in a specific encoding and enable translations to/from the canonical XML encoding.
> Because all alternative encodings must abide by the TOSCA semantics, they can only diverge in how they represent their alternative encoding. For example, two YAML implementations may be able to consume and produce a valid Service Template XML, but may encode the Service Template differently in YAML. These diverging YAML implementations can still interoperate by translating to XML. However, if YAML interoperability is desired a set of translation rules between canonical XML and YAML need to be agreed upon.
--
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]