Ted Goddard writes:
That seems too harsh for the human-pasting-into-ssh case-- isn't it
acceptable for both operations to fail together with one error?
(Unfortunately, it might no longer be clear to the client which
operation the error is associated with.)
How will the client know whether to expect one or two rpc-reply
elements? Assumably it will expect two, thinking that it has
sent two and will hand waiting for the second one. Or it will
expect one (having bailed early during the generation of the
first rpc and stumbled blindly into the generation of the
second one) and will be confused over getting the second one.
This ambiguity-with-the-possibility-of-a-hand is exactly
the sort of fuzziness we need to avoid in order to define
a clean, clear, usable API.
Note, however, that this argues against the use of a simple
pre-processor, .....
not against the use of <?eom?>. <?eom?> could still be correctly
detected by
an XML parser.
How would it be detected in your CDATA case?
When the <?eom?> is embedded in the CDATA section, the XML parser
ignores it, because it's CDATA. It's only seen as a processing
instruction outside the CDATA section.
It can only be ignored it there's a preprocessor that's
parsing enough of the xml to see that it's inside a CDATA
section and can then ignore the <?eom?>.
Thanks,
Phil