-1

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)

closed as primarily opinion-based by Martijn Pieters, gnat, user40980, GlenH7, Kilian Foth Apr 28 '14 at 15:13

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    Check out this q: stackoverflow.com/questions/241819/… – Jeffrey Kemp Apr 28 '14 at 7:01
  • 2
  • In your particular example, the attributes seem to be describing each individual PAYMENT, rather than the whole body of PAYMENTS so it doesn't make sense to have them at that level - what if one payment happens to be a different payment type or currency? Anyway, personally I'd make the currency and payment type as additional elements on each payment - that way each payment is a self-contained entity, and may be easier to parse (IMHO). Imagine if you wanted to combine two sets of payments into one - it would not work unless both had the same currency and paymenttype. – Jeffrey Kemp Apr 28 '14 at 7:04
  • 2
    Yes, you said that in your question. I'm just pointing out that hardcoding that assumption into your design now may prove to be a limiting factor in the future; whereas a more general design (one that allows combining different payment types in the same document) may be better in the long run. BUT, you know your system better than me. – Jeffrey Kemp Apr 28 '14 at 7:09
  • 1
    @downvoter: care to comment ? – now he who must not be named. Apr 28 '14 at 7:19
3

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.