Sample JSON Pointer implementation in Java
Francis Galiegue
I've been resuming work on my project recently (I've been only really
doing maintenance work for the last few months), and have started with
JSON Pointer, since this is an essential part and the draft has
changed quite a lot.
So, I thought I'd share what I did. The difficulty with the spec as it
stands, when it comes to parsing, is the caret. It can only be
followed by ^ or /, so I resorted to regexes:
The key in this code is REFTOKEN_REGEX. You will note that this regex
_also matches an empty string_.
Algorithm in pseudo-pseudo-code:
strip initial #
while (input_is_not_empty) {
read first char of input, must be a /;
strip /;
apply regex, grab what this regex captured, unquote it, record it.
}
Why this works is actually all in REFTOKEN_REGEX.
Consider:
#/^a
After stripping the initial #, we stumble upon a /, OK, good, now the input is:
^a
But the regex returns an empty string. Which means, at the next
iteration of the loop, a ^ will be read, which is not a slash:
failure, illegal JSON Pointer.
This is how I do it with the spec as it currently stands, and I hope
it will help others. And this is also why I expressed the desire for ^
to become a generalized escape character: you don't have to resort to
a regex to parse, and regexes are a very difficult subject ;)
(seasoned regex practitioners will have noticed that I use Java's
possessive quantifiers; as far as I can tell, only Java, perl and PCRE
have these in the current regex library landscape, but in this very
case it doesn't really matter, the "normal* (special normal*)*"
pattern is the meat of this regex ultimately)
Hope this helps,
--
Francis Galiegue, fgal...@gmail.com
"It seems obvious [...] that at least some 'business intelligence'
tools invest so much intelligence on the business side that they have
nothing left for generating SQL queries" (Stéphane Faroult, in "The
Art of SQL", ISBN 0-596-00894-5)
Xample
Francis Galiegue
> You probably need negative look behind with a compliant Regex engine. In
> that matter you will be able to match a char without involving it into the
> matching splitting result.
I don't see where negative lookbehind would be useful tbh. Except if
you want to split, yes.
However, ECMA 262 regexes, for instance, don't support these.