|
Marc Clifton wrote: Lots of legacy systems or old API's that never got updated to JSON.
Exactly.
|
|
|
|
|
Message Closed
modified 12-Jan-21 10:41am.
|
|
|
|
|
It looks pretty good - ReSharper is going nuts on it but who cares!
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Dang, what did Raddius say or do, he is trusted member of ![Green Alien | [Alien]](https://www.codeproject.com/script/Forums/Images/alien.gif) 's court.
|
|
|
|
|
perhaps he tried to delete the post, and the system made the message closed because others responded?
I thought it weird as well.
|
|
|
|
|
It appears he posted a link to something that is verbotten.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
I've found that .NET XML serialization works fine and is relatively simple as long as .NET is doing the round-tripping. I've occasionally had to write my own serializers, but that's usually fairly trivial.
Adapting it to an existing schema or otherwise-specified form is a PITA. Instead of being able to say "handle this in XML", you essentially have to write code that implements the schema. This of course sucks, because the schema changes all the time (trust me, it's in the rules). You only get basic parsing out of the .NET XML support if you go this route.
Software Zen: delete this;
|
|
|
|
|
Some guy somewhere had a bad dream and woke up with the idea: now how can I make something totally confusing and complicated which computers can read effortlessly but humans will find totally incomprehensible? He came up with XML and ticked all the necessary boxes/requirements perfectly.
Personally I am not a fan of javascript but boy did they get that JSON stuff right. Whatever programming language you care to use the JSON data exchange is dead easy to follow and debug. Leave the hard interpreting stuff to computers, not humans. For god's sake: that is why we designed them for !!!
|
|
|
|
|
That's what killed me: I have a working implementation in Json but needed (evidently) to have it work in XML too.
Json: it just worked. Next?
XML: my life is a miserable series of pointless failures
cheers
Chris Maunder
|
|
|
|
|
Sounds like a job interview. 
|
|
|
|
|
I use XML all the time with LINQ in C#. It's easy and simple.
"I used to write COBOL, now I can do anything..."
|
|
|
|
|
It was designed by a committee and shows it. When I use XML I try and use attributes to store the data, it makes the payload much smaller and I avoid nesting if possible. LinQ is good with XML and XDocuments.
|
|
|
|
|
The XML-hype is history. try json it is smaller, better readable and a lot of parsers can handle it.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
I never had to suffer through this kind of pain. I mostly worked on a system that was originally developed when memory and CPU time couldn't be frittered away on messages the size of .jpgs. Our proprietary language prefixed pack(n) to the type to control a field's width, and it was easy to predict how it would lay out a struct. Developing everything in the same language and standardizing on endianism made it possible to read/write structs directly from/to messages that used TLV encoding (type=parameter id, length=bytes, value=struct, nested if necessary). Very efficient, and no serialization or deserialization.
But processors were upgraded independently, so an interprocessor protocol had to remain backward compatible. In rare cases, this meant that an adapter in release n+k had to convert a message received from a processor still running release n.
modified 12-Jan-21 18:16pm.
|
|
|
|
|
Chris Maunder wrote: Is anyone actively using XML as a data transport format?
Gosh yes, in a number of ways:
0: storing encrypted ftp credentials for desktop apps (yep, right out in the open on a web server) they get changed annually or as needed.
1: advertising program updates for desktop apps
2: uploading client data from desktop apps to a ftp/web server for processing, then maybe reporting
3: downloading client data from web apps to desktop apps (sql server 'for xml' is great) the xml loads directly into a datatable...life is good.
Of course, it helps when you control both ends (creation and consumption) of the xml content. 
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
I see XML (and even more: HTML) as a binary format. Not suitable for human consumption.
XML is OK for something generated as a binary serialization, untouched by human hands. Evaluated as such, XML qualities are mediocre. I cannot imagine any binary Tag-Length-Value format worse than XML, by any standard. XML has a single force: You can edit it using vi! (Or for that sake: cat 0 > filename )
Not too long ago, I asked (in General Programming) for reactions to my proposal of have a friend of mine provide a lot of tabular data as Excel tables, rather than vi editable files. That was more or less universally condemned: Either, he should provide data as a vi editable text file - in the class of XML, CSV, YAML, JSON ... - or I should develop a tailor-made domain-specific data entry application, doing a complete validation of all input data. Thinking that an Excel sheet might contribute to validation, whatever checks were added, was just naive and worthless.
I accept the arguments for a data entry application, as long as we recognize that text based binary formats such as XML, CSV, YAML, and JSON, are unfit for human consumption. They are binary: You have to be concerned about the representation, with regard to use of special characters, quoting, length restrictions, ... The contents isn't free. So, let's make data entry applications that are free. How easy is that, with XML, CSV, YAML or JSON as the user level data entry format?
Once we have come that far: Why not use a truly binary format, most likely TLV based? If you admit that the user should never edit the file directly, neither with vi nor cat 0 > file, what is then the advantage of using XML, HTML, CSV, YAML, JSON, ... ?
If anyone insists on obtaining the information in an "editable" format, generating it from a binary TLV representation is usually quite trivial. For the applications I manage, I can easily provide stored information in either "editable" format, or even (to some degree) accept input in those formats. Yet, any "editable" format is secondary. Simple tree structures, those that you can easily edit using vi (or cat 0 > filename) are easily handled, but if the data structures require cross-linking, you may need to use a some domain dependent data entry (or data manipulation) tool. You just can't handle complex structures neither in XML, YAML nor JSON; they have to be managed with specialized tools.
The essential point for this discussion: XML, as well as other "editable" formats, is completely unsuitable for anything but the most primitive data entry. I'd much rather read a table of input data from an .xlsx file that I can preview in Excel than from a an XML, CSV, YAML or JSON file that I can preview in vi (or for that sake: cat filename > less).
That's me. I recognize that others recognize vi as the ultimate data manipulation tool. (In its days, managing peek and poke was also considered essential to be recognized as truly qualified.)
Sometimes, I feel like an old, stubborn, ancient grandpa. At the same time, those vi (or cat 0 > filename) guys really belong to the generation before me
|
|
|
|
|
<snicker> many years ago my boss dictated that xml will be the transport format for the bank. Once you hit multi million complex records xml choked the server so that was one failed project (of many). We then converted back to csv.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Mycroft Holmes wrote: <snicker> many years ago my boss dictated that xml will be the transport format for the bank. Once you hit multi million complex records xml choked the server so that was one failed project (of many). We then converted back to csv.</snicker>
FTFY
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Chris Maunder wrote: Is anyone actively using XML as a data transport format?
Jabber does.
and it's run over LOW BANDWIDTH networks too 
|
|
|
|
|
Maybe I’m biased because I’ve been working with XML since it was invented, but I love it. My experience with it predates object serializers and whatnot, and I still find it simpler to roll my own much of the time to ensure that the output properly expresses the object’s purpose and usage.
I use JSON for transport where appropriate, such as pulling data into a Vue app, but whenever I need to model data in JSON, I quickly lose patience. The absence of a named root node, namespaces, and attributes leads to a pretty weak representation of the facts that does a poor job of conveying the designer’s intent.
Some have argued on this thread that XML is a binary format and not for human consumption, but I would much rather be given some XML to interpret than a bunch of JSON if I am tasked with querying the data. And a named end tag is pretty handy; not a fan of counting curly brackets!
Of course, XML is supported by a suite of very mature standardized tools, the likes of which simply don’t exist in the JSON world yet.
Cheers,
Keith
|
|
|
|
|
The ability to describe, and not just store, your data and abide by a published schema while remaining flexible and easily transformable and human readable is definitely a wonderful thing. I will give you that.
cheers
Chris Maunder
|
|
|
|
|
Your points are spot on. XSD is the best data description language I have encountered. I use XML Spy to create my schemas and then everything under the sun can read the schema and produce working code that is schema compliant. I was really disappointed with JSON schema, one would think they would have plagiarized from xml schema but no... perhaps the people that like JSON are dealing with flat or very limited hierarchies? Perhaps the are lacking variant nodes (choice). And perhaps they do not have to deal with patterns in strings for legacy systems?
|
|
|
|
|
Every so often you come up against a problem that XML is perfectly suited to address.
Not that long ago I needed to convert hierarchical CMS data into a structured, multi-file CSV format. I was translating content between two CMSssss.
Creating an XML rendering format made exporting the content maintaining hierarchy and relationships trivial. XSLT was the ideal tool to manipulate the XML and re-write it as CSV.
Doing it as code would have taken *a lot* longer, but I had an advantage that I spent a lot of time working with XSLT in the past. This approach is definitely not for the beginner.
As a transport medium, there's better choices these days that weren't widely adopted or invented when XML was in its heyday.
|
|
|
|
|
I have been using XML for data transmission and for data specification since 2000. What I like most of XML and XSD is that I can define several namespaces for different fields, this way, whenever I get a tag (e.g. <price>), it has implicity the scope of such tag, there are no doubt whether the <price> belongs to a scope or to another because it comes with its namespace (e.g. <price> can be "books" or "pencils"). If you define good XSD files, the XML will be parsed and be XSD-compliant with any language (C#, Java, Python...), serializing the XML documents into objects and viceversa.
[There are other great things of XML that I really like, but it is not the aim of this discussion.]
When I have to deal with personal data or some data regarding "money" (bills, business, purchases...) I always use XSD because I want to map the correct data into the correct field. For other, not sensible, data I use JSON.
Important note: Beware of namespaces, the most common error when parsing is when namespaces are in-lined. Some XML are produced badly and the receiver launches weird errors that make developers eventually hate XML. I think that it can be the reason for your intolerance this morning 
For data transmission, if the bandwidth is a problem, you can use EXI (Efficient XML Interchange (EXI) Format 1.0 (Second Edition)), which is better than compressing (gzip) JSON. But make sure that sender and receiver can manage EXI.
To sum up, JSON is very easy, but I still prefer XML/XSD for important data or data that must be signed, verified or checked.
|
|
|
|
|
Yes, we use XML in my company with some complex schemas. But since the beginning we have used LiquidXML to define the schema and generate the code (C++ and C#), otherwise it would have been a nightmare. But I must admit that it works fine: the process is quick, we can easily manage versioning and performances are good. But don't look at the generated code, it's awful!
In the last developments, we now use Json (manually) but the data structures are less complex so it's not really comparable.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
