search

raml-org / raml-tck

Test Compatibility Kit for RAML 1.0
http://raml-org.github.io/raml-tck/
8 stars 10 forks source link

Functional Utilities for TCK #21

Closed blakeembrey closed 7 years ago

blakeembrey commented 8 years ago

Unrelated to the output of the TCK, will there be official utilities for working with the output structure? For example, the biggest thing I'll require is expanding the type system into full JSON, then passing that JSON object to something that creates a validation function (I'm assuming this kind of utility exists, since the workbench does validation on examples). If I opt-in for the JSON structure entirely, will I be able to use the utilities I need?

ddenisenko commented 8 years ago

For example, the biggest thing I'll require is expanding the type system into full JSON

Please elaborate on how do you thing this may look. In details if possible.

then passing that JSON object to something that creates a validation function

I do not think we will ever make validation to work with JSON. Also, we do not have any "local" validation, it is always for the whole RAML file and any of its dependencies/overlays/extensions.

Though, what we are currently thinking about is to invent and implement some way to jump from JSON back to AST node so user cal call some methods when needed.

blakeembrey commented 8 years ago

Well, what it looks like really depends on what the JSON looks like, but:

var typeInfo = tck.document.types.fakeType // This needs to be accepted by the functionality utility, which means it may need to be expanded to collect references.

createValidator(typeInfo, options)

Ok, so there's currently no way to use the type system to validate data? That's a slightly separate concern, but it's required for libraries like Osprey. I was given the impression there was some validation logic existing somewhere.

ddenisenko commented 8 years ago

var typeInfo = tck.document.types.fakeType

This may work for getting type AST. This will contain data regarding what user typed in the code. I thought you want to have something we call "runtime type", meaning the interpretation of a type's code and its whole hierarchy. I.e. something meaningful to validate samples against.

Ok, so there's currently no way to use the type system to validate data?

It depends on what you mean. We do validate examples against the types internally in the parser. We use runtime types for that. And, it is not something related to TCK JSON.

blakeembrey commented 8 years ago

Ok, it sounds like what I want are runtime types. Can I use the runtime types with the TCK output? What is a "runtime type" (to clarify, what functionality does it expose)?

It'd be good to see the type system conversion into a "runtime type" separate from the rest of the infrastructure since it's going to be used a lot and under high load.

ddenisenko commented 8 years ago

Can I use the runtime types with the TCK output? What is a "runtime type" (to clarify, what functionality does it expose)? Runtime types are something, which is a result of calculation on top of AST. AST itself displays what user typed in code. Runtime types are a result of analysis of types and their dependencies and is a representation of type hierarchy. Like validation, it is not a product of TCK JSON.

But, if we invent a way of jumping from TCK JSON back to AST, you will probably have a bridge.

blakeembrey commented 8 years ago

So, can I get a JSON-based "runtime type" according to what you've stated above or does it already work like this? I would prefer to never have to access the AST layer and just work with objects instead, that would allow me to be able to create the validation layer separately from the parser.

ddenisenko commented 8 years ago

1) You can not get runtime type as JSON at the moment. These are objects with methods.

2) What I was talking about above is of how to jump to AST node in order to get runtime type from JSON. So you have a procedure, which analyses AST in its JSON representation. And at some point you meet, in example, a method, or a type. And you want to analyse it: see which ancestors it have, what type it is, what properties and facets it gets from hierarchy etc.

Right now you cant do that while analysing JSON because there is no mechanism of navigation from dumped JSON to AST node and you need AST node to get that runtime type. What can be improved here is to introduce a mechanism to jump from a type/method/whatever in JSON to its AST node counterpart, and -then- ask it for runtime type, which is an object, not JSON.

blakeembrey commented 8 years ago

I would prefer to never have to access the AST layer and just work with objects instead

Tooling could be utilities, no? Anyone who needs that in-depth analysis probably doesn't use the JSON anyway, right?