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

[Mario Salzer <mario@xxxxxxxxxxxxx>]

Elliotte Rusty Harold wrote:
> ><?xml version="1.0" parser="yes"?>        utilizes a real XML parser
> >
>
> No real XML parser will accept this.
>
> ><?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?
>
> These are not processing instructions.
>
> I think before you try to create new specs based on XML, you really 
> need to understand XML at a level well beyond that of a casual user.

Ok, after posting to this list, I found out this myself. It seems
this was just another exception from the list of exceptions in the
XML spec. And I also figured out, that the w3c now deprecated PIs,
but I still don't see the reason to distinguish the <?xml..?> thing
from processing instructions, nor do I see, where everybody else
found the sentence in the spec that proved this.

But I actually don't want to start a discussion on this point (the
others are more interesting), and after all a <?rpc whatever=... ?>
may be more appropriate, if anyhow existing XML parsers often just
don't let the application see the contents of the <?xml...?> pseudo
tag.


>
> Short version: This is a very bad idea.
>

Short answer: Not helpful.

> Medium version: see 
> http://www.cafeconleche.org/books/effectivexml/chapters/14.html

Medium Answer: Gives an very interesting reading and I'll probably
order that.

But now look at this. If XML-RPC didn't have a history, and __I__
was free to design it from start, then it would read like this (second
paragraph):
http://erfurtwiki.sourceforge.net/?id=IfXmlMinusRpcWasReallyXml

>
> Long version: Read Effective XML.
>
> This proposal violates many principles of good XML design, even such 
> basic principles as well-formedness. This proposal is fundamentally 
> flawed, and cannot be fixed. It is damaging to XML-RPC. It is 
> damaging to XML.

The draft was NOT AT ALL meant to violate the XML standard, and it
was also NOT meant to yield not-well-formed documents. If you found
such an example, just point me to it, this obviously then was a
typing mistake!

Second, I didn't attempt to define XML syntax, I defined XML syntax
for use with a protocol eventually to be called "XML+RPC". The thing
was about not to leave everything unclear and unmentioned like UserLand
did.

What I tried in that draft, was to consolidate on the things that
were effectively used in XML-RPC, and that make sense to use in
XML-RPC. The history of XML-RPC is:
* nobody ever used comments (and everybody who does in a RPC call
  MUST be a stupid)
* there ever wasn't a DTD for XML-RPC, and if you invented your own,
  then this simply means: incompatible (see below)
* nobody ever used attributes in XML-RPC, and if you do, then you
  again are incompatible (see below)
* again only a stupid would output a CDATA section for <boolean>, which
  is only allowed to contain the literal strings "0" or "1" - so why
  should it be allowed to use CDATA inside of <boolean>?
* nobody ever used XML namespaces with XML-RPC (which was not possible
  because of the missing DTD) - so why allowing it?

DTDs and attributes: Just imagine, your own DTD and tag attributes
with XML-RPC, and see this pretty cool example:
...<param>
     <rpc:value><int>&fiftytwo;</int></rpc:value>
   </param>
   <param>
     <value><int real-value="NIL">-1</int></value>
   </param>
May well be a convinience, but effectively let's other implementations
uninformed of the real values here.


IMHO the XML-RPC spec has started as a lightweight alternative to
SOAP. And I believe it should remain lightweight, and nobody should
introduce DTDs or fluffy features like attributes and bonus tags and
types that nobody else could recognize in the end. More features does
not mean a better protocol.
However, I don't say that only because SOAP restricts XML syntax,
XML-RPC should be restricted even more. But things that are effectively
not used until today, shouldn't be allowed at all.

>
> Boiled down, what this proposal says is you do not want to use XML 
> for RPC calls. That's fine--XML is not the solution to all 
> problems--but please don't call your new syntax XML, and honestly I'd 
> much prefer it if you didn't make it look anything like XML so as to 
> avoid the inevitable confusion among users.

The whole discussion is probably about the discrepence between the
people that call everything XML that just looks well-formed, and the
ones that need all the fluffy features of XML before they get happy.
 
True, there are ways to do RPC without XML, but it's also true that
you could also already do RPC with all the bonus functionality XML
offers: SOAP.
XML-RPC was meant to be a lightweight alternative to SOAP from the
very beginning, no need to add unused functionality. Optional features
aren't also the solution to all problems.

mario