Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reusable validator #58

Open
ericprud opened this issue Apr 26, 2017 · 6 comments
Open

reusable validator #58

ericprud opened this issue Apr 26, 2017 · 6 comments
Labels
Milestone

Comments

@ericprud
Copy link
Contributor

It's common to create a validator with a schema and test many instances against it, e.g. an ingestion validator for a web service.

- interface ShExProcessor {
-     Promise validate((USVString or RDFGraph) schema,
-                      (USVString or RDFGraph) graph,
-                      ShapeMap shapeMap,
-                      optional ShExOptions? options);
- };
+ interface ShExProcessor {
+     Validator validate((USVString or RDFGraph) schema,
+                        optional ValidatorOptions? options);
+ };
+ interface Validator {
+     Promise validate((USVString or RDFGraph) graph,
+                      ShapeMap shapeMap,
+                      optional ValidationOptions? options);
+ };
@ericprud ericprud added this to the 2.0 milestone Apr 26, 2017
@ericprud ericprud added the IDL label Apr 26, 2017
@gkellogg
Copy link
Contributor

Two interfaces? Standard for WebIDL lately has been to use promises. If you did want to define a synchronous interface, perhaps simply use a different method? The method could be defined to simply invoke the promise. There's some discussion of that here, but I'm not sure why this is really necessary.

In any case, the Validator type would need to be defined, but should probably simply return ShapeResults.

@ericprud
Copy link
Contributor Author

I don't think this is a synchronicity issue. I think it's just one of whether the API caters to the use case of reusing a schema for multiple validations. If the web API is any predictor for this, the shex.js interface is quite general, e.g. you can start it with some data and then throw successive schemas at it, or even start it with a schema and data and interrogate multiple ShapeMaps, but the common case is to start it with a schema and then query it iteratively with successive data and shapeMap reqs.

@gkellogg
Copy link
Contributor

Okay, I can see the value in this. Not sure that in WebIDL a call can return an interface, as it's not really object-oriented. Perhaps both methods are in the ShExProcessor interface, and a parse method returns an instance of a Validator type, which is then used as an argument to a validate method. The validate method could also be as it is now, but have schema be (USVString or RDFGraph or Validator); this is a short-cut for when the validator is not reused..

@jessevdam
Copy link

I would define it more like

- interface ShExProcessor {
-     Promise validate((USVString or RDFGraph) schema,
-                      (USVString or RDFGraph) graph,
-                      ShapeMap shapeMap,
-                      optional ShExOptions? options);
- };
+ #sync version
+ interface ShExProcessor {
+    ShExSchema parseSchema(USVString schema) raises(ShExError);
+    Graph parseGraph(USVString or RDFGraph) raises(ShExError);
+    USVString validate(ShExSchema schema,
+                      Graph graph,
+                      USVString shapeMap,
+                      optional ShExOptions? options);
+ };
+ interface ShExSchema {
+ };
+ interface Graph {
+ };
+ #async version
+ interface ShExProcessor {
+    Promise<ShExSchema> parseSchema(USVString schema);
+    Promise<Graph> parseGraph(USVString or RDFGraph);
+    #Input parameters are also promises so that both schema can be parsed in parallel
+    Promise<USVString> validateAsync(Promise<ShExSchema> schema,
+                      Promise<Graph> graph,
+                      USVString shapeMap,
+                      optional ShExOptions? options);
+ };

I do not have a separate Validator class as this would break the async construct with the Promises. If the shapeMap would be also a promise object, it would be in theory possible to have all 4 elements running in parallel (would not be practical doh I think).

@ericprud
Copy link
Contributor Author

I wrote this up without Promises in asyncAPI.

@gkellogg
Copy link
Contributor

Looks like it's a synchronous, rather than asynchronous API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants