Hi Paul, pardon my ignorance but Iâm not sure what you mean by ârailroad diagramsâ. Would you mind expanding a bit?
Thanks,
Chris
From: paul.m.jordan@bt.com <paul.m.jordan@bt.com>
Sent: Thursday, December 10, 2020 6:22 AM
To: adam@onecommons.org; Chris Lauwers <lauwers@ubicity.com>
Cc: tosca-comment@lists.oasis-open.org
Subject: RE: [tosca-comment] RE: Wording of operation outputs description
I would also be interested on working on a formal statement of the syntax â not that I have much experience in doing it.
There is much more tool support JSON schema and so I agree that it would be more useful in the long term that BNF. I suspect that there is much in the current draft of v2 which would be difficult to describe in JSON schema
today and definitive schema will probably mean having to make changes to the spec. So a definitive schema can probably only be a long term goal.
In the nearer term creating a ârailroad diagramâ would, I think, be helpful for tutorials and to highlight areas of the syntax which need attention. These diagrams can be drawn manually or from EBNF.
I would have expected that moving from EBNF to JSON schema would be a mechanical process but a brief search has no turned up any references to a suitable technique or tool.
Paul Jordan
OSS Specialist
BT Technology |
Tel +44 (0) 3316252643
| paul.m.jordan@bt.com
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.
British Telecommunications plc
R/O : 81 Newgate Street, London EC1A 7AJ
Registered in England: No 1800000
From: adam souzis <adam@onecommons.org>
Sent: 10 December 2020 03:12
To: Chris Lauwers <lauwers@ubicity.com>
Cc: Jordan,PM,Paul,TNK6 R <paul.m.jordan@bt.com>;
tosca-comment@lists.oasis-open.org
Subject: Re: [tosca-comment] RE: Wording of operation outputs description
I think developing a JSON schema is a great idea and something I would volunteer to help with. It would make it much easier for tools to syntactically validate TOSCA templates and help us remove ambiguity from the spec.
As a side note, OpenAPI also uses json schema so this might help interoperability with interface definitions.
I think a BNF-like definition would be more work and considerably less useful.
Thanks,
Adam
On Thu, Dec 3, 2020 at 9:00 PM Chris Lauwers <lauwers@ubicity.com> wrote:
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>
Sent: Tuesday, December 1, 2020 2:34 AM
To: Chris Lauwers <lauwers@ubicity.com>; tosca-comment@lists.oasis-open.org
Subject: RE: Wording of operation outputs description
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:
- If the template MUST not include the clause then there is no need to mention the behaviour of the processor and so the last sentence should be deleted.
- On the other hand I suggested using SHOULD because I thought it might make implementations easier. However Iâve not written a processor and may be wrong about that.
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.
A processor may ignore, warn or error if they are encountered.
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
OSS Specialist
BT Technology | Tel +44 (0) 3316252643 | paul.m.jordan@bt.comThis 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.
British Telecommunications plc
R/O : 81 Newgate Street, London EC1A 7AJ
Registered in England: No 1800000
From: Chris Lauwers <lauwers@ubicity.com>
Sent: 30 November 2020 00:58
To: Jordan,PM,Paul,TNK6 R <paul.m.jordan@bt.com>; tosca-comment@lists.oasis-open.org
Subject: RE: Wording of operation outputs description
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
Sent: Wednesday, November 25, 2020 2:56 AM
To: tosca-comment@lists.oasis-open.org
Subject: [tosca-comment] Wording of operation outputs description
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
OSS Specialist
BT Technology | Tel +44 (0) 3316252643 | paul.m.jordan@bt.comThis 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.
British Telecommunications plc
R/O : 81 Newgate Street, London EC1A 7AJ
Registered in England: No 1800000
á