OK, baseball reference. :) Well, it's always easy to criticize. :) If we want TOSCA to be better, we need to better participate in the process. There is an open JIRA for ARIA to consolidate all our errata into a single proposal for OASIS.
On Tue, Nov 28, 2017 at 1:00 PM, DeWayne Filppi <dewa...@cloudify.co> wrote: > bush league == amateur hour > > On Tue, Nov 28, 2017 at 10:49 AM, Tal Liron <t...@cloudify.co> wrote: > > > Sorry, I did not understand that last comment about "bush league"! > > > > But yes, the spec is known to be flimsy and self-contradictory. In the > end, > > we must make a choice on how to implement things in ARIA, while taking > into > > account that other TOSCA implementations might interpret the spec > > differently. (Even more ideally: provide configuration options for ARIA's > > parser, so that it could better work with YAML files created for other > > TOSCA implementations. We have a few of these configuration options > > already.) > > > > This is exactly why the current PR for ARIA-1 is important: it > introduces a > > broad test suite for TOSCA syntax and grammar, which obviously follows > the > > interpretations we made for ARIA. But it can be run on other TOSCA > parsers, > > too, at least giving us information as to where other parsers differ in > > their interpretations of the spec. > > > > I will say that our rules of thumb has generally been: 1) if a strict and > > loose interpretation are possible, choose the stricter one, and 2) keep > the > > "spirit of the spec" in mind: object-orientation and enforcement of the > > parent type contract. > > > > On Tue, Nov 28, 2017 at 12:44 PM, DeWayne Filppi <dewa...@cloudify.co> > > wrote: > > > > > Wow. That is reeeeeeeeeeeaaaaaaaaaaaaaaaaaaaaaaally bad and bush > > league. > > > > > > On Tue, Nov 28, 2017 at 10:42 AM, Tal Liron <t...@cloudify.co> wrote: > > > > > > > "Examples" in the spec routinely break the syntax of the spec... I > > think > > > > it's best not to trust them. > > > > > > > > On Tue, Nov 28, 2017 at 12:40 PM, DeWayne Filppi < > dewa...@cloudify.co> > > > > wrote: > > > > > > > > > I suppose it lets you name interfaces whatever you want, which is > > > > confusing > > > > > because of other areas of the spec. Note that there are tons of > > > examples > > > > > in the spec without the "type" specified. > > > > > > > > > > On Tue, Nov 28, 2017 at 10:27 AM, Tal Liron <t...@cloudify.co> > wrote: > > > > > > > > > > > I mentioned this to you in the previous thread: the "type" field > is > > > > > > required for interface definitions according to TOSCA syntax. So, > > > even > > > > if > > > > > > it's the same as what you are inheriting, you must specify it. > > > > > > > > > > > > On Tue, Nov 28, 2017 at 12:04 PM, DeWayne Filppi < > > > dewa...@cloudify.co> > > > > > > wrote: > > > > > > > > > > > > > Now that the 'subclassing' problem has been resolved, > overriding > > > > > > interface > > > > > > > methods is breaking. Simple example: > > > > > > > > > > > > > > tosca_definitions_version: tosca_simple_yaml_1_0 > > > > > > > > > > > > > > imports: > > > > > > > > > > > > > > - aria-1.0 > > > > > > > > > > > > > > node_types: > > > > > > > > > > > > > > T1: > > > > > > > derived_from: tosca.nodes.Root > > > > > > > interfaces: > > > > > > > Standard: > > > > > > > create: > > > > > > > implementation: > > > > > > > primary: i1.sh > > > > > > > delete: > > > > > > > implementation: > > > > > > > primary: i1.sh > > > > > > > > > > > > > > The error, using Aria in the ARIA-1 branch: > > > > > > > > > > > > > > Validation issues: > > > > > > > 2: required field "type" in > > > > > > > "aria_extension_tosca.simple_v1_0.definitions. > > InterfaceDefinition" > > > > > does > > > > > > > not > > > > > > > have a value > > > > > > > > > > > > > > > > > > > > > > > > > > > >
