Should Json really be under System.Text? about corefxlab

[whoisj]

Agreed. Json is serialization, not text. The fact that Json is a text (as opposed to binary) format is irrelevant.

[KrzysztofCwalina]

Where should it be? i.e. what namespace do you suggest?

[whoisj]

@KrzysztofCwalina depends. How expansive are we expecting the number of JSON support objects to be? As expansive as XML? Then why not System.Json (akin to System.Xml)? Otherwise, System.Runtime.Serialization seems like the logical choice.

Thoughts?

[KrzysztofCwalina]

System.Json is already taken: https://msdn.microsoft.com/en-us/library/system.json.aspx

[whoisj]

System.Json is already taken: https://msdn.microsoft.com/en-us/library/system.json.aspx

And we're not welcome to expand/improve upon it?

[KrzysztofCwalina]

You are more than welcome to expand/improve upon it. But I would not mix two alternative APIs in one namespace.

[whoisj]

Existence to two API is going to be confusing. There really is no good answer here but I assert that System.Runtime.Serialization1 is more correct thanSystem.Text` for JSON serialization code.

[akoeplinger]

@KrzysztofCwalina has the System.Json you're linking above actually shipped anywhere outside Silverlight? If not, would it make sense to just create a new set of APIs in that namespace for .NET Core? the namespace is just too good to waste it 😄

[KrzysztofCwalina]

Such namespace reuse has the potential to create confusion. For example, people who search for it might be taken to the irrelevant documentation, samples, blog posts, etc.

Also, I did not mention it in the past, but this library in corefxlab is probably not super suited for non-textural JSON representations.

[akoeplinger]

Such namespace reuse has the potential to create confusion. For example, people who search for it might be taken to the irrelevant documentation, samples, blog posts, etc.

I've actually seen plenty of confusion around that specific library, since it once shipped in a preview of .NET Framework, so yeah 😄

Also, I did not mention it in the past, but this library in corefxlab is probably not super suited for non-textural JSON representations.

What's "non-textural JSON"?

[KrzysztofCwalina]

What's "non-textural JSON"?

I was just trying to replay to the concern in the first two comments stating that JSON is not tied to text. I probably misunderstood the comments. I thought they implied that JSON could conceivably be non-textual. Now I re-read the comments and they are more conceptual than implying any actual non-textual JSON formats.

[whoisj]

they are more conceptual than implying any actual non-textual JSON formats.

Correct - at least wrt my comments. JSON is a serialization format and it should be treated as such. Like XML, INI, and other formats it also varyingly human readable, but it is not just text. Editing JSON in a program like Word sounds awful (put possible). 😏

[KrzysztofCwalina]

@whoisj, I hear you and I agree. It's just I need a good proposal for a namespace to make your observation actionable.

[whoisj]

I submit System.Runtime.Serialization.Json

[KrzysztofCwalina]

This library has nothing to do with serialization, i.e. you cannot pass objects to be converted to JSON. It's more similar to BinaryWriter, XmlWriter, and such.

[whoisj]

But both BinaryWriter and XmlWriter are serializing data. I'm confused.

Is this more of a System.IO.Json thing then? That makes relatively little sense - sadly.

[KrzysztofCwalina]

I don't think we have the same definition for "serializing". The writers are not serializing anything by my definition. As I said above, to me serailization would mean you can pass objects in to get them converted to transmittable data that can be round tripped back to object. These APIs won't let you write our arbitrary (or even POCO) objects automatically.

System.IO.Json would be very strange. I agree.

[whoisj]

I think I need to take a fresh look at what we're naming. 😉

Looking at the code explicitly, @KrzysztofCwalina is right. This is not serialization but a text formatter. This is far more akin to System.Text.StringBuilder than to serialization. The correct location for this is likely in System.Json. Since there's concern about name confusion, then perhaps right in System.Text makse the most sense; unless we expect there to readers, writer, and validators. In which case System.Text.Json does make some sense - but once we're writing, reading, and validating we're getting very close to serializing and deserializing.

All one would need to do that would be an attribute or two and class that could reflect and serialized marked up objects.

I'm torn.

[KrzysztofCwalina]

closing this till there is a proposal for a better namespace

[jakesays-old]

How about something like System.Text.IO.Json - given that json is 'implemented' as a text format and readers and writers are about i/o, this would indicate that the classes perform json related i/o on textual data.. or something like that.

[KrzysztofCwalina]

I am not convinced that the addition namespace node ("IO") adds a lot of value.

[jakesays-old]

Yeah I'm not either. Really stretching on this one.