XML serialization functionality [was Re: Trolltech, Qt 4.2 and KDE 4.0]

Frans Englich frans.englich at telia.com
Sun Mar 12 18:02:09 GMT 2006

On Sunday 12 March 2006 17:12, Thiago Macieira wrote:
> Hello everyone
> Trolltech is aware that KDE 4.0 will require many features present in Qt
> that are currently not there or not even scheduled for Qt 4.2. And we're
> also aware of discussions going on about extending our classes to provide
> that functionality and of patches being made against qt-copy in hope of
> being rolled into Qt in the future.
> While we have our own set of priorities and features for Qt 4.2, we are
> committed to seeing KDE 4.0 happen and using an unpatched Qt 4.2, without
> the need for crude hacks or unnecessary subclassing. Therefore, Trolltech
> is placing one resource to interact with the KDE developer community and
> finding out what such needs are.

How nice of Trolltech.

Something I for a long time have had on my mind to mail qt-bugs about is a 
class I've written, SAXSerializer[1]. It is a QXmlDefaultHandler sub-class, 
receives SAX events and produces a QByteStream. That is, it takes XML on the 
logical level(infoset'ish) and produces bytes such that one can save it.

I find that a fairly common thing to do, to produce XML. If one doesn't use a 
mechanism such as SAXSerializer, one has to resort to various not XML aware, 
primitive and error-prone methods such as manually concatenating strings(it 
gets non-wellformed, escaping and encoding issues, etc).

The class is missing certain features such as unit tests and producing 
QByteArray/encoding(currently it produces a QString).

I wonder, is Trolltech interested in anything like SAXSerializer? It is rather 
generic, fits in Qt's scope, and it wouldn't surprise me if Trolltech's 
customers needs it(IMHO, of course). Personally, I am of course happy to see 
it maintained by Trolltech..

KDE impact: very small. This is about pushing generic code upstream.

Also, for code submissions it would be great if you had coding 
convenventions/guidelines online so one could produce more correct code.



Not done, but nevertheless:


More information about the kde-core-devel mailing list