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

Replace template preprocessing with re-mapping. #129

Closed
wants to merge 1 commit into from

Conversation

handrews
Copy link
Contributor

@handrews handrews commented Nov 4, 2016

This change attempts to minimally address the awkwardness and
shortcomings of the current URI template preprocessing approach.

In addition to its dubious aesthetics, preprocessing does not
help with using values other than the current instance or an
immediate property (for an object instance) or element (for an
array instance).

Instead, use an object to map the variable names to locations in
the instance with relative JSON pointers. This neatly solves both
the UTF-8/illegal variable name problem and the complex data
structure problem with the same mechanism.

This is close to what is proposed in #52, but that proposal includes
several other related features which are understandably more
controversial. I think this is actually closer to the original
proposal that preceded #52 in the old repo.

The change from vars to hrefVars was inspired by the terminology
being used in the JSON Home project. While compatibility with JSON
Home is not a goal, I like how this clarifies exactly what the keyword
is intended to do.

This change attempts to minimally address the awkwardness and
shortcomings of the current URI template preprocessing approach.

In addition to its dubious aesthetics, preprocessing does not
help with using values other than the current instance or an
immediate property (for an object instance) or element (for an
array instance).

Instead, use an object to map the variable names to locations in
the instance with relative JSON pointers.  This neatly solves both
the UTF-8/illegal variable name problem and the complex data
structure problem with the same mechanism.

This is close to what is proposed in json-schema-org#52, but that proposal includes
several other related features which are understandably more
controversial.  I think this is actually closer to the original
proposal that preceded json-schema-org#52 in the old repo.

The change from `vars` to `hrefVars` was inspired by the terminology
being used in the JSON Home project.  While compatibility with JSON
Home is not a goal, I like how this clarifies exactly what the keyword
is intended to do.

Since `base` is also a template which was defined to use the same
preprocessing as `href`, it likewise gets a corresponding `baseVars`.
@handrews
Copy link
Contributor Author

handrews commented Dec 5, 2016

Even if we go this route, I suspect we'll need to re-do this based on #179 so I'm just going to close it out for now to reduce confusion.

@handrews handrews closed this Dec 5, 2016
@handrews handrews deleted the hrefvars branch February 20, 2017 00:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant