[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Wording of operation outputs description
|
Thanks Paul, I prefer the first alternative (with the last sentence deleted), because (at least in current v2.0 syntax) output definitions are fully supported in interface type definitions.
BTW, we’ve had discussions about formalizing the TOSCA syntax, although I’m not aware of any actual progress in this area. We’ve had debates whether a schema definition (e.g. using JSONSchema or XSD) is appropriate or whether a BNF-like
syntax definition should be used. Thanks, Chris From: paul.m.jordan@bt.com <paul.m.jordan@bt.com> Chris, I agree most of your amendments as they are more precise. But I am not sure about changing from SHOULD to MUST for two reasons:
As a general point I don’t like restrictions on the syntax which are expressed only in text like this one; it almost as if we really have two different definitions which apply in different situations
but have similar content. Ideally I would like spec which could be validated by a JSON schema. So I prefer either: When operation outputs are included as part of
interface definitions in node and relationship type definitions, the output definitions may include mappings onto attributes of the node or relationship type that contains the definition. When operation outputs are included as part of interface
type definitions, output definitions
can only define output types and MUST not
define any mappings. Or When operation outputs are included as part of
interface definitions in node and relationship type definitions, the output definitions may include mappings onto attributes of the node or relationship type that contains the definition. When operation outputs are included as part of interface
type definitions, output definitions have no meaning and SHOULD not be included. A processor may ignore, warn or error if they are encountered.
Paul Jordan This email contains information from BT that might be privileged or confidential. And it's
only meant for the person above. If that's not you, we're sorry - we must have sent it to you by mistake. Please email us to let us know, and don't copy or forward it to anyone else. Thanks. We monitor our email systems and may record all our emails. From: Chris Lauwers <lauwers@ubicity.com>
Thanks Paul for the recommendation. To make things even more clear, perhaps we can explicitly distinguish between output definitions in *interface definitions* vs. output definitions in *interface type definitions* as follows: When operation outputs are included as part of
interface definitions in node and relationship type definitions, the output definitions may include mappings onto attributes of the node or relationship type that contains the definition. When operation outputs are included as part of interface
type definitions, output definitions
can only define output types and MUST not
define any mappings. A processor may ignore, warn or error if they are encountered. Please let me know what you think. Thanks, Chris From:
tosca-comment@lists.oasis-open.org <tosca-comment@lists.oasis-open.org>
On Behalf Of paul.m.jordan@bt.com TOSCA v2.0 csd03 section 4.3.6.4.1 includes text in the description of the outputs keyword which led me to the erroneous conclusion that the output data type could not be defined in an interface operation type definition. Could the text please be clarified. My suggested wording is: When operation outputs are included as part of node and relationship type definitions, the output definitions may include mappings onto attributes of the node or relationship type that contains the definition. When operation outputs are included as part of interface definitions, output definitions have no meaning and SHOULD not be included. A processor may ignore, warn or error if they are encountered.
Paul Jordan This email contains information from BT that might be privileged or confidential. And it's
only meant for the person above. If that's not you, we're sorry - we must have sent it to you by mistake. Please email us to let us know, and don't copy or forward it to anyone else. Thanks. We monitor our email systems and may record all our emails. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]