[Qt-interest] How to: parse an xml file with tags

[Ross Driedger]

On 16-Feb-10, at 4:53 PM, qt-interest-request at trolltech.com wrote:

>
> Message: 5
> Date: Tue, 16 Feb 2010 22:52:56 +0100
> From: Thiago Macieira <thiago at kde.org>
> Subject: Re: [Qt-interest] Qt-interest Digest, Vol 15, Issue 148
> To: qt-interest at trolltech.com
> Message-ID: <201002162252.56625.thiago at kde.org>
> Content-Type: text/plain; charset="iso-8859-15"

Preamble:  Thanks for your prompt responses, Thiago.  Nothing I say I  
mean against you personally and I really appreciate the time you spend  
on this mailing list.  Cheers.  I got a little worked up when  
envisioned a lot of hard work going up in smoke over a decision that I  
disagree with.  So you can mention that there are some passionate  
feelings in the user community.

>> So is it part of the Qt philosophy to ignore established standards  
>> and
>> invent something new that is incompatible with anything else?  Sounds
>> more like Microsoft's way of doing things.
>
> I thought that was the entire point. If the other standards were  
> good enough,
> there wouldn't be a need for Qt. Qt exists because they aren't good  
> enough and
> we are making something that is better than they are.
>
> That goes for well-established standards like POSIX, STL, Win32, etc.

Really?  From my point of view, the real value of Qt is to abstract  
platform differences which are from Venus, Mars and Pluto when viewed  
side by side.  Of course,  others choose Qt for reasons other than  
that, but I can only speak for myself.  Standards that are platform  
and vendor independent are there because of the motivation to play  
nicely and be able to work well with others.  No one really wants to  
be locked in a data or implementation jail subject to the whims of  
decision makers to are unknown.  As much as I enjoy the benefits of Qt  
I want the option to switch a component without a massive redesign.   
DOM, as an example, provides an independent and unbiased foundation  
from which to design -- I want the option of implementing in the QDom*  
classes or in Xerces or even MS' implementation of XML -- OK maybe  
that is stretching it a bit.

In short, I don't want to be locked into Qt or any framework if there  
is a perfectly workable, living and viable open standard, especially  
when Qt uses that standard already.

>
> Another good example is also DOM: lots of people asked for DOM for  
> WebKit
> after Qt 4.4. We stood our ground and didn't add the hundreds of  
> classes that
> would be required for full DOM API. Instead, we made QWebElement,  
> which still
> allows you to do what you want to do (access the object tree inside  
> the HTML
> world) but without introducing an "alien" API.

To me that sounds like a reasonable and workable compromise to a  
difficult problem.

[...]

> And I will emphasise again that we are discussing Qt 5. QDom is not  
> going
> anywhere in Qt 4.

Well, I am thankful for that.  ;)

I didn't think you were going to pull those classes until the next big  
rev.

[...]

> I really don't understand why. Why are you not happy about a  
> decision we
> haven't made that may or may not influence you in 3 years (or more)?

Well, it sounded like a 'done deal'.

[...]

> So, yes, I will continue to recommend QXmlStreamReader because it's  
> more
> efficient and I believe it's the future. You may disagree with me.


I haven't looked at these classes as doing so would represent a  
distraction presently, but I really do understand the motivation  
behind a new and light-weight of dealing with XML; it is certainly  
your prerogative to promote what you think is most productive based on  
your knowledge of the framework.  Even more important when dealing  
with smaller devices that don't have the GB of memory that most  
desktops have these days.

Anyway thanks for the discussion; you know how I feel about this part  
of the framework and I get a sense of yours; if we might disagree  
about some of the philosophy and implementation that is to be  
welcomed: if we all had the same needs and requirements computing  
would be a much more boring subject.

:)

Ross

Ross Driedger
ross_at_earz.ca



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20100216/d7f721ca/attachment.html