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

[Martin Duerst <duerst@xxxxxx>]

At 18:44 04/01/22 +0100, Mario Salzer wrote:

> Ok, after posting to this list, I found out this myself.

Next time, *please* run your proposal through a real XML parser,
which will tell you immediately, before you send it out.


> 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.

http://www.w3.org/TR/REC-xml#NT-PITarget says that a PI target
(the name of a PI) may not start with 'xml', in any case combination.
http://www.w3.org/TR/REC-xml#NT-XMLDecl defines the XML declaration,
which does not allow any other pseudoattributes than version,
encoding, and standalone (in this order!). Similar for the
Text Declaration in http://www.w3.org/TR/REC-xml#NT-TextDecl.


> 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!

ok, good.


> 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?

No, actually namespaces and DTDs don't work together that well.


> 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.

Documenting current use is not a bad idea. As long as the syntax allowed
is a subset of XML, calling it XML is okay, too, because that's what it
is. After all, all XML subtypes are subsets of well-formed XML, because
all of them come with some restrictions. These restrictions are usually
done where XML intended them to be done.

Subsetting XML syntax features is in general a bad idea for reasons
already pointed out, but I do not consider it bad enough to think that
we should forbid it. It is also not what BCP70 recommends, but if you
explicitly think you understand the issues and want to do something
else than what BCP70 says, that should not a priori by forbidden,
nor should it invalidate BCP70.


> 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.

Besides putting the parameters in your proposal at the wrong place,
it also seemed to me that all these parameters created additional
optional features, which is exactly what you say you don't want.
So why not just stay with no parameters at all?


Regards,    Martin.