>>>>Good advice.
>>>>
>>>>>Agreed. What you don't want is to have both XML and JSON for different things. Pick one solution and stick to it...
>>>>>+++ Rick ---
>>>
>>>I disagree with Rick Strahl. There are times XML is advantageous, and times JSON is advantageous. If you're doing only data processing, JSON is better. If you're interacting with people who may need to view the data in its stored form, XML is better. XML is easier to understand, and it's worth the extra programming overhead to keep both parsers in your project based on people needs, and data needs, if you have more than trivial people needs.
>>>
>>>My $0.02.
>>
>>It would however be confusing if you end up having a mx-n-match between them on a single interface -- sort of like "Japlish" (mixing of Japanese and English) or "Spanglish" (mixing of Spanish and English) - which I've been guilty of doing on occasion.
>
>No it wouldn't. Permanent data storage should be in a database form. Inter-process communication data should be in a serializable form, such as XML or JSON. There should be no confusion whatsoever.

FWIW, I worked on one application where it made sense to store the data as XML and convert it to tables when using it. The client was a company that made multiplexers for utility substations and the application was the tool that their customers used to monitor and configure their networks of stations. At any given time, the application would be looking only at a single network and there needed to be an easy way for the company to pre-configure the network data and give it to their customer at the same time they delivered the hardware. A customer might have multiple such networks, but they'd never need to have them loaded into the application at the same time. We stored the network configurations as XML externally, and when the customer opened a network, converted to DBFs (and then ultimately into an object model on which we actually operated).

Tamar