Sam Ruby wrote:
...
I will again point out that the current format allows for empty summary and/or content elements.
I have seen errors that the requirement for the inclusion of such elements would have prevented.
I have seen no arguments as to why placing such empty elements would impose an unreasonable burden on implementers.
...
Again speaking based on experience using XML formatted protocol data:
As far as I can tell, using empty elements to signal the *absence* of information is a potential source of interoperability problems. For instance, clients may behave differently based on whether some piece of data exists, but fail to handle an empty string value as "no" value.
So, at a minimum, the spec would need to be clear about the fact that if something has no text content, it means "this information is missing" instead of "this information is present and has an empty string value".
Also keep in mind that people *will* break rules as long at it simplifies their own work and they get away with it. It'll be hard to explain why it's necessary to marshall an element with no text content, if clients will treat the absence of this element the same way (and they will). If both notations carry the same semantics, and both are likely to be used no matter what the RFC says, it IMHO would be wise to allow both.
Best regards,
Julian
