5 ms·
My guess is that more and more people are coming to the realization that xml is great for fluid text and document formatting, but too ambiguous to serve as a da
by seanalltogether 12y ago
My guess is that more and more people are coming to the realization that xml is great for fluid text and document formatting, but too ambiguous to serve as a data structure format.
XML nodes and children are just too slippery. I've actually argued with enterprise developers about why serving the following format was a terrible idea.
<user>
<id>123456</id>
<name>Joe</name>
<account>Account 1</account>
<account>Account 2</account>
</user>
- dietrichepp 12y agoThe other problem is that you never know how a data structure would map to XML. <user id="123456" name="Joe"> <account name="Account 1"/> <account name="Account 1"/> </user>
- Igglyboo 12y agoIs there a hard and fast rule for deciding when something is an attribute and when it is a child? I would have personally done <user id="123456" name="Joe"> <account>Account 1</account> <account>Account 2</account> </user> but I've never actually produced XML, only consumed.
- seanalltogether 12y agoBoth ways still leave the structure ambiguous. Should <user> be mapped to an associative array of mixed objects, or to a fixed object using a custom mapper to shove the account objects into their own sub array.
- treve 12y agoIf you're looking for a generalized way to map an XML structure to primitive types, you're going to have a bad time.
- pjungwir 12y agoMy rule is that things are almost never attributes. :-) There is less flexibility there. Escaping seems harder, and you can't have sub-elements or lists. Avoiding attributes makes things more verbose, but then that's XML for you.
- fizx 12y agoI've followed the rule that if the property is of the underlying data representation, use children, and if it's a (meta-ish) property of the XML implementation, or some contextual annotation, use an attribute. In your example, something like: <users total="100" cursor="123453"> <user> <id type="int">123456</id> <name type="string">Joe</name> <accounts> <account> <name type="string">Account 1</name> </account> </accounts> </user> </users>
- algorithmsRcool 12y agoCould you please humor me as to why this is a bad idea? I don't seem to have an eye for these types of problems.
- Retra 12y agoCheck the other replies to this. They've filled it in a bit...
- nkurz 12y agoI don't understand either, and would benefit from a clear statement. Is there a universally agreed upon better way? Are those criticizing it presuming the particular use case of schema-less data deserialization and saying that it doesn't fully specify the object?
- throwawaymsft 12y agoIn JSON the server would have returned account as an array with 2 elements. In XML you are left to figure that out for yourself. It's hardly clear that there could be several accounts but never several ids. (Yes, you can wrap it with an <accounts> node and make your data extremely verbose.) What about attributes? Should we ever expect them on the user? What if there's an attribute id as well, is it the same? (Oh, just download a schema to tell you what to expect! Argh...)
- xorcist 12y agoThat's nothing. Just today I had the equivalent of: <user id="12345"> <name id="12345">Joe</name> ... </user> Let me count the ways that's underspecified in ways that can go wrong... (The actual problem I tried to solve was unrelated to this. The fields are in latin1 while the document itself is in utf8, with attributes specifying content type. It all validates apparently.)
- barrkel 12y agoObjects are edge-labeled graphs. XML documents are node-labelled trees with more than one type of leaf. The ambiguity is intrinsic and ought to have been obvious long ago.