3 ms·

> I'm convinced the author was not aware of attributes, or for some reason held a grudge against them. The XML heyday is a little before my time, but I think a

by dtech 4y ago

> I'm convinced the author was not aware of attributes, or for some reason held a grudge against them. The XML heyday is a little before my time, but I think attributes were considered improper design compared to only using tags by purists.

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 ago
  Note 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...
wiredfool 4y ago
My recollection of the personalities involved is that the author is absolutely not a purist. He's a pragmatist, and this was simple, understandable, and worked well enough at the time. He was doing this because he needed the functionality, not because it was the best design possible. I also think that this design was also reasonably well aligned with the internal XML capabilities of Frontier.
- masklinn 4y ago
  > My recollection of the personalities involved is that the author is absolutely not a purist. The opposite really, half-assed "good enough for me" is also very much visible in RSS.

by dtech 4y ago

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 ago
Note 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...

wiredfool 4y ago

My recollection of the personalities involved is that the author is absolutely not a purist. He's a pragmatist, and this was simple, understandable, and worked well enough at the time. He was doing this because he needed the functionality, not because it was the best design possible. I also think that this design was also reasonably well aligned with the internal XML capabilities of Frontier.

masklinn 4y ago
> My recollection of the personalities involved is that the author is absolutely not a purist. The opposite really, half-assed "good enough for me" is also very much visible in RSS.