2 ms·
It is arguably "good design" because tags are infinitely extensible whereas attributes are not. For example in the case the author supplied imagine if you want
by kevincox 4y ago
It is arguably "good design" because tags are infinitely extensible whereas attributes are not.
For example in the case the author supplied imagine if you wanted to add a compression type to a member. Your only choice would be an attribute which means that it can only be a string.
<struct>
<member name="faultCode"><int>-123</int></member>
<member name="faultString"><string>some fault</string></member>
</struct>
If in the original you could add a new element inside the member like
<compression>
<algorithm>zstd</algorithm>
<dictionary>dict7</dictionary>
</compression>
Not the best example but the point stands. Of course the complaint is valid because while extensibility is valuable you need to weigh it against the cost of the verbosity (both in use and for developers).
- jmillikin 4y agoNote that in the specific case of XML-RPC, extensibility is forbidden by the spec: A <fault> struct may not contain members other than those specified. This is true for all other structures. We believe the specification is flexible enough so that all reasonable data-transfer needs can be accomodated within the specified structures. If you believe strongly that this is not true, please post a message on the discussion group. At one point the author did intend to allow elements to contain user-defined children[0], but it seems like their position changed between that mailing list post and the spec update 7 days later. [0] https://web.archive.org/web/19991010205056/http://discuss.userland.com/msgReader$2135 https://web.archive.org/web/19991010205056/http://discuss.us...