[Kss-devel] Server response format

[Jeroen Vloothuis]

Balazs Ree wrote:
>> ...
>> <kukit:param name="html">
>>      &lt;h1&gt;it worked
>> </kukit:param>
>> ..
>>
> 
> I tried to explain this to you in irc. This would be wrong, because 
> instead of the structured html you become a simple text node, but the 
> content is not even a string as we know various things happen with non-
> ascii character like enter. You could do this:
> 
> <kukit:param name="html" value="<h1>it worked</h1>" />
> 
> and then in the attribute you'd use the escaping you need inside 
> attributes (which is btw not the same that you need in the html code).
> 
> Would this be better? I rather like to read an xml document then a string 
> of two pages that contains an encoded structure, but indeed we can start 
> thinking of this.

The value as attribute you suggest now sounds fine by me.

> But, imo, put it in any way, it's the issuer's responsibility to issue 
> valid html code. If invalid html is issues, the result will be broken at 
> some point and you can't do anything against it (besides an attempt to 
> same fix it as we currently do with beautifulsoup) So if your concern is 
> this, I am afraid there is not much to do.

It is indeed my concern where the responsibility lies. Also the current 
format is deficient in the way to you must always pass valid xml even 
when just want to pass a string.

>> 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.
> 
> Indeed this is true, no strict parsing is possible. I would add that even 
> if we had dtd it would be no use at all, since the only ones that reads 
> this are the clients that parse this xml with the builtin xmlhttprequest 
> code, and they don't care for dtd. Even if you have a schema it would be 
> useless.

The point of the schema is not that a schema itself would be useful but 
that a good format should be able to validate.

> The question is not the design choices at this point. This format 
> developped in an evolutionary way that it should be simple to parse, 
> handle on the client, and that it works cross browser. The question is 
> what reason we have to change it right now. Some of your reasons may be 
> valid, so we may return to this topic later, but let's not turn the 
> "enable kss from pure python" story to a "change the commands transport" 
> saga.

My biggest reason for bringing this up is to make clear that end users 
of the pure Python library need to know what they can pass in.