aboutsummaryrefslogtreecommitdiffstats
path: root/lib/Makefile
diff options
context:
space:
mode:
authorLars Thorsen <[email protected]>2017-01-12 16:49:40 +0100
committerLars Thorsen <[email protected]>2017-02-22 10:00:18 +0100
commit00294041cd3c6f66598a50b57abf27e6a35e277f (patch)
treea479e0f3668179943324df40a1f012faec8fd07e /lib/Makefile
parent4f56fb3e9120e92ff7b0700402707ad032114311 (diff)
downloadotp-00294041cd3c6f66598a50b57abf27e6a35e277f.tar.gz
otp-00294041cd3c6f66598a50b57abf27e6a35e277f.tar.bz2
otp-00294041cd3c6f66598a50b57abf27e6a35e277f.zip
[xmerl] Correct bug handling multiple documents on a stream
Change how to interpret end of document to comply with Tim Brays comment on the standard. This makes it possible to handle more than one doc on a stream, the standard makes it impossible to know when the document is ended without waiting for the next document (and not always even that). Tim Brays comment about the trailing "Misc" rule: The fact that you're allowed some trailing junk after the root element, I decided (but unfortunately too late) is a real design error in XML. If I'm writing a network client, I'm probably going to close the link as soon as a I see the root element end-tag, and not depend on the other end closing it down properly. Furthermore, if I want to send a succession of XML documents over a network link, if I find a processing instruction after a root element, is it a trailer on the previous document, or part of the prolog of the next?
Diffstat (limited to 'lib/Makefile')
0 files changed, 0 insertions, 0 deletions