Scope information for additional properties about jschon HOT 4 CLOSED

The term 'scope' comes from 'dynamic scope' described...

Thanks for linking. TIL.

the existence or otherwise of child property nodes for additionalProperties should impact your sort algorithm, as the schema wouldn't know about those properties anyway

The idea was a somewhat obscure ability for a schema to hint whether additional properties should be ordered before or after all other properties. Right now it's hardcoded to 'after'. Considering patternProperties do work, I'll close this one.

from jschon.

Hi Ilya, glad to hear you are finding jschon useful. Could you perhaps provide an example to clarify the issue you are describing, and what your expectation would be?

The Scope.schema attribute is there primarily to be able to generate absolute URIs for annotation and error output - though it's also used in $dynamicRef resolution. So yours is an interesting use case because it's an 'unexpected' way of using Scope.schema! It has been in the back of my mind to look more carefully at how boolean schemas are processed - there's an issue with poor error messaging for e.g. "additionalProperties": false - and I have a very speculative hunch that these issues might be related.

from jschon.

My tool reorders properties to be in the same order as they're defined in the schema. It relies on mapping from the document to the schema that's in the evaluation results. (Welcome to see how it's implemented, there's not much to it.)

For additional properties, I would expect a mapping from each such otherwise unknown property to the additionalProperties that allows it, though I'm not sure if that's all that obvious for it to happen.

from jschon.

Okay, I see that you're using the instpath and path attributes of scope nodes to create a mapping from document nodes to schema 'sort keys', and I see how this enables you to sort document nodes that have been validated by properties. (This is very cool, btw!)

So I've worked through your test case, adding an additional "foo" property to your test instance, and setting the inner additionalProperties value to True in the test schema. I understand that in your _traverse_scope function, you might expect to visit a scope child node with instpath pointing to /ranges/0/foo, with a corresponding path of /properties/ranges/items/additionalProperties.

The difficulty here is that document evaluation is done from the perspective of the schema, and the resultant structure of the scope tree reflects the evaluation path taken through the schema and any referenced schemas. (The term 'scope' comes from 'dynamic scope' described here). So in the scope tree, under a properties node, you'll have child nodes for each of the properties that appear in the schema (each of those child nodes being associated with a property subschema), but you won't have any such child nodes under an additionalProperties node, because the value for additionalProperties is just a single subschema, against which any additional properties are validated. The names of any properties validated by the additionalProperties keyword are stored in the annotation of the corresponding scope node.

Having said all that, unless I'm missing something, I don't think the existence or otherwise of child property nodes for additionalProperties should impact your sort algorithm, as the schema wouldn't know about those properties anyway?

from jschon.