>>For configuration JSON is not always great because it requires string encoding for special characters. Tabs, carriage returns/linefeeds and back slashes have to be encoded. It's easy to hand edit JSON and get it wrong because there's a character you forgot needed encoding. Some of this can be mitigated if you use a decent JSON editor (like VS Code) that provides syntax coloring.
>
>Encoding was something I was wondering about because I knew I had to do some of that the last time I used your classes (wwhttp stuff). It seems though that your .Serialize() method does the encoding at least for CR/LF (I just checked).

The tools of course handle the encoding - that's not the issue. COnfiguration files often are hand edited after the fact which is the whole point of readable configuration files. Otherwise you'd just store it in a database or some custom format :-)

Hand editing JSON can be problematic. XML also has encoding issues, but you can mitigate with CDATA sections that accept raw text. JSON doesn't have such a thing.

it's not a big deal, just something to consider.

>> XmlToCursor and CursorAdapter are much faster than manually parsing XML or creating JSON/Parsing Json on the fly.


>For the last project, for results returned from the server, most times I used XmlToCursor() for small results sets as it was fairly easy when using the switch to infer the structure from the cursor that I had already created, so did not have to get into using schemas.

Yes XmlToCursor()/XMLAdapter is going to be much faster than any hand code solution. That code is highly optimized and it's very fast at generating output.

Even in .NET JSON output is considerably slower than XML output for most scenarios, but speed isn't the only story - ease of use and easy compatibilty are the main reason JSON tends to be a better universal choice especially if you are exposing data publicly.

>
>>Personally I would probably opt for JSON just because it easily works with objects which is what I work with and XML doesn't make that natural. JSON is also the more 'modern' thing - but I guess we can take that with a grain of salt.
>
>I want to be open to what this new developer might throw at me - if they are already using json a lot for other projects, I might as well learn it if it is the "new" thing - besides, if they have to write a bunch of stuff to give me xml, their rate is a whole lot higher than mine so it makes sense for me to adjust what I am doing than for them to run up their bill :-)


Agreed. What you don't want is to have both XML and JSON for different things. Pick one solution and stick to it...


+++ Rick ---