Hi Tal,
Yes, if we want to avoid special-purpose code in the TOSCA parser, then we should investigate if we can accomplish JSON and or XML validation using the schema constraint. While weâre at it, we should discuss changes to the schema constraint
itself:
- I have done a number of project where it was necessary to define the schema of configuration data using YANG. We did this by specifying a YANG module in the schema constraint associated
with the string property that contained the configuration data.
- However, this is technically not a correct use of the schema constraint, since the schema constraint expects the schema itself to be provided as (inline) string data.
- Expecting schemas to be provided inline is unrealistic for all but the most trivial schemas.
- We should consider using âschema artifactsâ instead.
- Unfortunately, artifact definitions can only be associated with node types and/or node templates, which makes the use of artifacts in data type definitions much more complex.
Iâll add this as a topic to our next TOSCA Language Ad-Hoc meeting
Thanks,
Chris
From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org>
On Behalf Of Tal Liron
Sent: Wednesday, January 8, 2020 12:17 PM
To: tosca@lists.oasis-open.org
Subject: [tosca] tosca.datatypes.json and tosca.datatypes.xml
These special types were introduced in TOSCA Simple Profile 1.2. Not much is said about them, but I am assuming that it is expected that parsers;
-
Validate that the content is indeed proper JSON or XML
-
Otherwise not change the data -- it should be left as a string (plain text)
This makes these types quite special indeed, because this kind of validation would have to be hardcoded in some way in the parser. There is no TOSCA constraint that could do that: unfortunately no simple regexp that could do the job. ;)
Because we are going to separate the Simple Profile from the grammar, I think we have to choose from the following options:
-
Remove these types and implement this feature via a constraint. The "schema" constraint (section 3.6.3.2) seems like a good candidate, however
from its description is seems like "schema" is intended to enhance these types, i.e. to add an XSD schema to "xml". Perhaps we can clarify and enhance this constraint: first argument would be "xml", "json", "yaml", etc., and the optional second argument would
be the schema for that format.
-
Move these types to be part of the grammar, just like "string", "map", "list", etc. (and of course remove the "tosca.datatypes." prefix from their names). I would also suggest that we might want to add a "yaml" type, for plain-text embedded YAML.
-
Remove these types entirely: they can't be in the Simple Profile (not without special hardcoded parser support), and keeping them in the grammar will add unnecessary clutter.
I'm leaning on #1, if only because the "schema" constraint is totally unclear to me right now, and I do think this kind of validation mechanism could be useful.
|