I have to design an xml structure to set standard data exchange with my client.
ID: 644429 • Letter: I
Question
I have to design an xml structure to set standard data exchange with my client.
We deal with payments and its related data.
At now, my XML data looks like this:
<PAYMENTS>
<CURRENCY>DOLLARS</CURRENCY>
<PAYMENTTYPE>CHEQUE</PAYMENTTYPE>
<PAYMENT>
<AMOUNT>100</AMOUNT>
// ALL OTHER DETAILS GO HERE
</PAYMENT>
<PAYMENT>
<AMOUNT>100</AMOUNT>
// ALL OTHER DETAILS GO HERE
</PAYMENT>
</PAYMENTS>
But one of my colleague managed to write a different version.
<PAYMENTS CURRENCY = DOLLARS
PAYMENTTYPE = CHEQUE>
<PAYMENT>
<AMOUNT>100</AMOUNT>
// ALL OTHER DETAILS GO HERE
</PAYMENT>
<PAYMENT>
<AMOUNT>100</AMOUNT>
// ALL OTHER DETAILS GO HERE
</PAYMENT>
</PAYMENTS>
(The currency and paymenttype tags are moved as attributes because they are not going to repeat again like payment)
But, I wonder what is the best method to represent this ? My way or the second one?
Are there any guidelines to this?
(Not sure if this helps: But, I am using C# for coding)
Explanation / Answer
Welcome to the number one problem of using XML as a data serialization format! Attributes vs contained elements - so useful in markup, so annoying in data serialization...
At any rate, assuming you are forced to go with the herd and use XML for data serialization, there are only three reasons to prefer attributes over elements:
If the field has it's own subfields.
If the field can repeat.
If the field is something you want to treat as heredoc.
All these cases apply for the design, not for the example set of data you have in hand. If a field in your data doesn't happen to follow any of these rules, but the design allows one of the rules to apply it, it should be an element.
The reason to prefer attributes over elements(unless one of the cases apply) is that even with LINQ to XML it's much easier to use attributes. Programming languages usually make it easier to say "I have an object, give me the contents of one of it's fields" than to say "Here is a pile of objects, fetch me one that fits a certain criteria".
Both CURRENCY and PAYMENTTYPE are - as you say - non-repeatable by design, and they are not compound, and they don't really need to be heredoc - so they should, by all means, be attributes. So should be, by the way, AMOUNT of PAYMENT, so you should probably write:
<PAYMENTS CURRENCY = "DOLLARS"
PAYMENTTYPE = "CHEQUE">
<PAYMENT AMOUNT="100">
// ALL OTHER DETAILS GO HERE
</PAYMENT>
<PAYMENT AMOUNT="100">
// ALL OTHER DETAILS GO HERE
</PAYMENT>
</PAYMENTS>
and consider which of these "ALL OTHER DETAILS" should really "GO HERE", and which should also be attributes.