Re: [tosca-comment] Feedback on TOSCA 1.3 spec

[adam souzis <adam@onecommons.org>]

It's not about typos, it is about reducing implementation complexity and mitigating aboutÂsecurity flaws from malicious input. Unless you have robustÂset conformanceÂtests that tests these edge cases I guarantee you there will be interoperability bugs with unexpected identifiers. If TOSCA used throughout a system, e.g. persisted in a database, input data will likely be handled by code that doesn't expect simple names to have carriage returns and invisible characters etc. (because that is let us politely say, unexpected and unusual) and you open yourself up to things like SQL injection attacks.

To answer your question about XML: Does TOSCA's YAML profile need to be compatible with its XML profile? If it does, how would you represent a TOSCA YAML identifier in a TOSCA XML file? I guess you would write an algorithm to escape the invalid characters? And then if you need to translate the XML back to YAML, you'd write code to recognize the escaped identifiers and unescape them? Just throwing an exampleÂout there to illustrate the complexity burden you are placing on implementations for little gain.Â

But I agree with you about this issue being exhausted at this point if these arguments don't make sense make to you.Â

On Sun, Mar 8, 2020 at 7:06 PM Tal Liron <tliron@redhat.com> wrote:

On Sun, Mar 8, 2020 at 8:45 PM Chris Lauwers <lauwers@ubicity.com> wrote:

That is all reasonable, but weâre narrowly talking about entity names (such as node templates, property names, requirement names, etc.), not the values for those entities.

But these are also values that are often validated by the parser. E.g. if you give a "bad" name to a requirement it should cause an error if it can't be matched at the node type or node template.

I'm really confused as to where this is all going. Typos can happen anywhere in any computer language, whether it's restricted to English's [a-zA-Z] or all of Unicode.

I'm sorry Chris and Adam, but I think this issue is exhausted as far as I'm concerned. I am trying to get from you some specific problem with the current lack of restriction and have not heard anything that looks specific to me. On the other hand, I've raised a few reasons why you would want to keep it unrestricted -- visual IDEs, separation between design and runtime elements, TOSCA generated from external systems, future uses that we don't even know about, the arbitrariness of picking just any set of rules (XML? why?) -- and have not gotten any arguments against them.