My remark about "typos" was specifically a response to Chris's last point about unfortunate copy-and-paste mistakes.
I feel I've responded fully to the SQL injection issue, which I insist is not enabled by TOSCA allowing arbitrary node template names, any more than our allowance for arbitrary string values in properties. If you are building SQL queries with literal values and not scrubbing them then I dare say you have more serious security issues than node template names.
I will respond only to new issues here to avoid repetition:
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?
Here's one way that would be fully compatible with TOSCA 1.0 (in YAML) to 1.3:
<node-template>
 <id> you can put any Unicode text here as long as you escape XML entities </id>
</node-template>
I know that TOSCA 1.0 (in XML) used an attribute for the ID, but I also don't know of anybody currently using that spec. Meanwhile, TOSCA 1.0 (YAML) to TOSCA 1.3 were published without specifying name restrictions. If we introduce a restriction in TOSCA 2.0, which will be quite different from the 1.X series, we could affect migration to 2.0. Are you suggesting that someone will want to convert a TOSCA 2.0 service template to TOSCA 1.0 in XML? I think node template names would be the least of their problems. Actually, all versions of TOSCA until now introduced breaking changes. We are hoping to run a tighter ship in the 2.X series, or at least make sure to upgrade the major version number when we introduce breakage.
It's worth pointing out that TOSCA's move to YAML involved fully embracing the type system in YAML 1.1 (with the exception of timestamps, which we've discussed separately in this mailing list). XML does not have a type system (no integers or floats, only CDATA) while YAML's has served us quite well as an underlying system for TOSCA's basic data types. It's very easy to take a YAML file and convert it to any programming language's primitives, hashmap, and array implementations. I've come to call this kind of data "Agnostic Raw Data (ARD)".
We could go even further: YAML 1.2 expands on extensibility, so that potentially we could even allow for TOSCA data types to be represented as custom YAML types. I wouldn't recommend we go in that direction, though, as it would also make it very hard to implement TOSCA parsers. You would have to find a YAML 1.2 parser library that allows for easy extensibility of types, and honestly most YAML libraries out there do not do a good job with it, if they allow for it at all. (Data types would also have to be defined separately from our service templates, because they would have to be parsed and initialized as YAML types before being used to parse the service template.)