[Kss-devel] Server response format

[Jeroen Vloothuis]

The current server side infrastructure generates XML/HTML output as a 
response (aside from a test renderer used in unit tests). This rendering 
has a problem in my opinion. I hope to illustrate the problems I see 
with it so that we can either discuss a fix/replacement or you can 
enlighten me on the design choices.

After alle headers etc. are generated the KSS response consists of:

<kukit:commands>
<kukit:command tal:repeat="command context"
      selector="div#demo" name="setHtmlAsChild"
      selectorType=""
      tal:attributes="selector python: command.getSelector();
                      name python: command.getName();
                      selectorType python: command.getSelectorType()">
     <kukit:param tal:repeat="param python: command.params" name="html"
             tal:attributes="name python: param.name"
             tal:content="structure python: param.content">
         <h1 xmlns="http://www.w3.org/1999/xhtml">it worked</h1>
     </kukit:param>
</kukit:command>
</kukit:commands>

Using the structure statement means that all output is passed as is. 
This has the implication of generating something like:

...
<kukit:param name="html">
     <h1>it worked
</kukit:param>
...

Code like that is obviously not valid XML. A problem with this is that 
it breaks the whole response parsing. Therefore you do not get nice 
local errors for the command which should actually break.

As far as I can see the current fix for this is to use BeautifulSoup to 
fix up any broken data. In my opinion this is a fix to a problem which 
should not be there in the first place.

For an application developer this implicit magic can have nasty side 
effects when debugging styling problems (due to a wrong fix).

Like I said earlier I think the approach is flawed from the start. There 
is no reason I can think of to alter the structure of the response 
document. What I mean by this is that all data should be escaped and not 
made part of the DOM.

So the earlier example would like like:

...
<kukit:param name="html">
     &lt;h1&gt;it worked
</kukit:param>
...

This would make it possible to write a schema for the KSS reponse and 
validate it against that shema. If you allow arbitrary data this will 
not be possible.

At the moment I do not see why escaping should not be default way. All 
actions that need DOM force any string anyway (for use with client side 
actions).

I would rather not duplicate the current behaviour (at least not until I 
understand why it is done this way) in the new kss.commands package. So 
please enlighten me on the design choices so that I may understand them.