XML+RPC vs BCP70 , <?xml?> processing tag abuse?

[Mario Salzer <mario@xxxxxxxxxxxxx>]

Hi, this is again about application/rpc+xml, discussion of an initial
draft available at:
http://erfurtwiki.sourceforge.net/draft-xmlplusrpc-pre00.txt

To allow limited XML parsers or even simple token parsers to understand
XML-RPC messages, I initially added a section on XML use restrictions.
There was already some feedback, and a revised draft will likely allow
a CDATA section then only for the <string> tag.

So basically the restrictions within this draft were:
* no XML namespaces (were never used)
* no XML comments (only stupids used that within RPC messages)
* no XML entities allowed, but &lt; &gt; &amp; mandatory
* no XML tag attributes (were never part of the spec)
* empty tags must be written in the long form:
  <empty></empty> instead of <empty\s*/>
* UTF-8 is the recommended encoding, and only Latin1 should
  eventually be used instead
* restricted tag nesting syntax (less fluffy as with UserLands spec)

All this was to eventually allow stupid parsers to use it, but then
the restrictions should not hurt existing implementations (which
most often however use full fledged XML parsers). So the draft defines
a restricted but conformant XML syntax (at least I hope so).

It however restricts how conforming messages should be generated by
a XML generation toolkit. Someone already pointed out, that it may
be difficult to make some XML libs not throw shortened <empty/> tags.
However the empty tag problem again only applied to the <string>
element (can't happen for anything else).

So actually somebody had the idea of letting the client (servers are
assumed to almost always use XML parsers anyhow) signalise, if it
really utilizes a XML parser or just a limited thing. But instead of
introducing any tag attributes (there currently are none), I had the
idea of abusing the <?xml..?> processing instruction for this task.
This could signalise, what syntax the XML+RPC client understood and
expected. For example:

<?xml version="1.0" parser="yes"?>        utilizes a real XML parser

<?xml version="1.0" parser="no""?>        server MUST send simple XML
                                          as defined by the draft

<?xml version="1.0" empty-tags="long"?>   needs <empty></empty>

<?xml version="1.0" accept-charset="ISO-8859-1"?>
(I don't think introducing <?rpc ... ?> was a good idea,
even if 3470 has a similar example. ;)

But as these xml processing instructions then didn't actually apply
to the document they were in, but instead control how the server
reply should be constructed - wasn't this then abuse of this tag
form?

The drawback of embeding such instructions however was, that this
then again could lead to two incompatible implementations instead of
unification. So are the XML+RPC format requirements in the current
draft to difficult to implement for XML toolkits, or fairly ok if
weightet against the fact, that they would allow for really fast
implementations on the other hand? 


mario