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

[Mario Salzer <mario@xxxxxxxxxxxxx>]

Martin Duerst wrote:
> ...
> >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.

My impression of 3470 was that it recommends enforcing restrictions on
XML syntax within ietf documents, if the restrictions actually accomplish
some interoperability task (and a few things in my draft are just contrary
to XML and multiple RFC3470 recommendations, because they were broken in
XML-RPC before).
While it's true, that some of the initial restrictions made are avoidable,
it's also true, that some XML syntax doesn't make sense at all within RPC
program glue. At least none of the eventual restrictions makes the generated
documents that invalid, that a conforming XML processor could not understand
it later.

The main problem with XML-RPC is that it exists. And it was misdesigned
from the very beginning, like I tried to point out with the
'<value type="string">...</' example. And my draft was meant to make
a standard out of something that was already misimplemented widely,
hence the various restrictions on things that didn't need to be restricted
if it wasn't that something already went wrong.

Comments don't make sense within RPC, as they could in general be
considered bloat for anything in the application/* (instead of text/*)
MIME types. However I admit, that I proposed that restriction because
of my general fear, that some w3c members again could add things like
<!--[if !mso]> to introduce extensions.

The most contreversial point likely is the no-short-empty-tags rule.
But I really believe, that if someone uses a full featured XML processor,
than there will also be a likewise advanced XML generation lib besides,
which supported this.

And if now XML-RPC was designed with the spirit of 'some weird syntax
with angle brackets' in mind (as Tim Bray commented it here), then
I say, just leave it that way and take an advantage of this by
consolidating on.
And also attributes already lead to divorced XML-RPC implementations
in the past, as Dave Winer himself pointed out once. Someone added again
a one-system-only extension by introducing a tag
'<object type="classname">...</object>'. While this is the best way to
utilize XML, introducing it was obviously against existing XML-RPC
implementations and its original semantic. Therefore I believe it's
important to forbid attributes, so nobody again could want to add such
features, which were totally against the original idea.
And also BCP70 clearly says, that there should be a clear ruling on
extensibility and that not too much points should reamain unmentioned.

For XML-RPC one cannot just take advantage of the X in XML, extensions
must be implemented in another way than breaking existing installations
and the compatibility goal. And I'm also sure I already know a better
way to do that (even if it's still a workaround) which is a lot better
than letting people randomly introduce new but incompatible data type
tags like <pointer/>, <null/> and <undef/>.

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

True, and actually because I didn't wanted that, I was pleased by the
idea to put such parameters into <?pi...?> where everybody would ignore
it later. (Someone again suggested me adding tag attributes for splitting
a XML-RPC standard into the 'weird angle bracket syntax' I suggested,
and the 'XML with whistles and bells' everybody else prefers).

However it's brain dead to make two different 'standards' just because
many people get totally furious about, that a XML document without
comments and tag attributes could break their XML processors.
It's still a goal to further simplify XML-RPC by explicitely disallowing
things like '<value>text...</value>' and '<string\s*/>' (or to at least
deprecate some of the more boring stuff).

mario