Make parsing location available to application code

Details

Description

The public review draft of the javax.json API does not make the parse location available to application code. Several members of the Toronto JUG indicated that this would be critically important to their adoption of the API.

It was suggested to create a Location type, and make location information available on request from JsonParser.getLocation(), and as a property of JsonParsingException.

I actually did ask one of the people who brought this up if it would be sufficient to put location information on the parsing exception only. He said no; he uses location information during his streaming XML parse, even when there are no syntax errors in the XML.

I don't know exactly what his use case is, but I can certainly imagine creating a system that throws an error when the data is semantically wrong. For example:

{
"id": 1234,
"firstName": "Alice",
"lastName": [1, 2, 3]
}

although the above is a structurally valid JSON message, an application would likely want to reject it because lastName should be a string, but we were given an array. The application's own error message would be much better if it could include location information.

One final thought: unfortunately, we'll have to make location information optional too: when we are streaming a tree of JsonValues through JsonParser, there won't be an underlying character-oriented stream to calculate a line and column number from.

We could still require implementations to provide location information when the underlying data is coming from a string.

jfuerth
added a comment - 05/Feb/13 2:09 PM The JsonLocation interface you've proposed looks good.
I actually did ask one of the people who brought this up if it would be sufficient to put location information on the parsing exception only. He said no; he uses location information during his streaming XML parse, even when there are no syntax errors in the XML.
I don't know exactly what his use case is, but I can certainly imagine creating a system that throws an error when the data is semantically wrong. For example:
{
"id": 1234,
"firstName": "Alice",
"lastName": [1, 2, 3]
}
although the above is a structurally valid JSON message, an application would likely want to reject it because lastName should be a string, but we were given an array. The application's own error message would be much better if it could include location information.
One final thought: unfortunately, we'll have to make location information optional too: when we are streaming a tree of JsonValues through JsonParser, there won't be an underlying character-oriented stream to calculate a line and column number from.
We could still require implementations to provide location information when the underlying data is coming from a string.