[Json] Some thoughts on the "text model" discussion

[Pete Resnick <[e-mail]>]

Like Matt said of the duplicate names discussion, I think we do appear 
to be converging (albeit more slowly) on a couple of possible outcomes 
in the discussion of the text model. I'll leave it to the chairs to 
truly summarize conclusions, but I did want to make a couple of 
observations that I hope can hone in on a few of those conclusions:

- People did quickly slide from my more overarching question about what 
makes up a JSON entity to the specific question about JSON strings in 
particular. Though clearly my aim was to inform the issue of strings, I 
was hoping we could come up with a more general principle. In the end, I 
think we made some good progress on figuring out those general principles.

- The discussion at the beginning regarding "a JSON object" vs. "a JSON 
text" was very revealing to me because it leads me to believe that 
nowhere do we have a general concept of a "JSON entity" aside from it 
encoding or representation in memory. I think that has made some of the 
discussion more difficult, but my sense is that we now share a more 
general view of what such a thing might be. This leads to another point:

- The use of the terms "JSON parser" and "JSON generator" is often 
conflated with things that I would refer to as a "JSON lexer" on the 
parsing end of things and an "JSON encoder" or maybe a "JSON token 
producer" on the generator end of things. That is, when I think of a 
"JSON parser", I think of something that understands the semantics of 
the JSON entity it is creating out of the JSON text it is parsing, and 
conversely a "JSON generator" knows about the semantics of the JSON 
entity it is turning into a JSON text from some in-memory 
representation. Some of the difficulty in the conversation is that we 
know of pieces of code that don't know about the semantics and therefore 
don't "know" whether they are dealing with Unicode characters or just a 
series of Unicode scalar values. (This caused similar confusions in the 
duplicate names discussion.) Requirements on things that have to know 
the semantics are different than the requirements on things that are 
simply lexers or encoders. How we explain that (and what language we use 
for it) in the documents is independent of the point that they are 
different requirements.

For each of these three items, I think if we end up with some 
explanatory text in the documents that helps make the appropriate 
distinctions (and note that I am being purposely agnostic on what the WG 
should say about each of them), I think that would help the clarity and 
implementability of the spec.

I'll leave it to the chairs to decide where to take the discussion from 
here.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - [phone]