Hi!

Is there some class to work with XML in MFC?

Thanks

"PYB" <ndisko> wrote in message
news:a484
> Hi!
>
> Is there some class to work with XML in MFC?
>
> Thanks


I've used http://www.codeproject.com/KB/cpp/markupclass.aspx with much
success and delight!

-- David

PYB wrote:
>
> Is there some class to work with XML in MFC?

Hi,

unfortunately I think that there is no XML class in MFC (at least, in
current state - maybe they might consider adding something in the
future...).

However, you can use 3rd party C++ XML libraries, like TinyXML, which is
open-source:

http://www.grinninglizard.com/tinyxml/

There is also interesting code on CodeProject, e.g.:

http://www.codeproject.com/KB/trace/...L_wrapper.aspx


Happy New Year,

Giovanni

Giovanni Dicanio <giovanniDOTdicanio> wrote in
news:eu66JAQbJHA.4276:

> PYB wrote:
>
> Hi,
>
> unfortunately I think that there is no XML class in MFC (at least, in
> current state - maybe they might consider adding something in the
> future...).
>
> However, you can use 3rd party C++ XML libraries, like TinyXML, which
> is open-source:
>
> [..]
>
> There is also interesting code on CodeProject, e.g.:
>
> [..]

I've used (all free, with various licenses):
- xerces (and xalan)
http://xerces.apache.org/
- libxml2 (and libxslt)
http://xmlsoft.org/
- wxWidgets (internally, they use expat, if I remember correctly...)
http://www.wxwidgets.org

Dave Connet

And I've been happy with XmlLite from Microsoft.

Brian

I also vote for xerces.

Especially if you want validation, proper support for encodings,
and also writing XMLs.

"Mihai N." <nmihai_year_2000> wrote in message
news:hain

> I also vote for xerces.
>
> Especially if you want validation, proper support for encodings,
> and also writing XMLs.

I was experimenting with MSXML a year or two ago - just to test some
concepts. I need a proper DOM and, of the ones mentioned so far in this
thread, only xerces and MSXML seem to have that.

I mean to get back and write some "proper code" soon, and I'd be interested,
if anyone knows, to hear how xerces and MSXML compare for ease of use?

Dave

David Webber wrote:
>
> "Mihai N." <nmihai_year_2000> wrote in message
> news:hain
>>
> I was experimenting with MSXML a year or two ago - just to test some
> concepts. I need a proper DOM and, of the ones mentioned so far in
> this thread, only xerces and MSXML seem to have that.
>
> I mean to get back and write some "proper code" soon, and I'd be
> interested, if anyone knows, to hear how xerces and MSXML compare for
> ease of use?
>
> Dave

I've used MSXML for several projects and I've maintained a project that
used xerces.

MSXML uses COM, so you have to get quite familiar with that. Most people
seem to write some kind of c++/mfc wrapper just to make the whole thing
digestable. My wrapper had a list of nodes , each node containing
attributes and a list of nodes. Then you can navigate using the familiar:
POSITION pos = m_node.GetHeadPosition();
while(pos)
etc
etc

The xerces implementation used more abstract iterators. They worked OK,
just a question of familiarity really.

One point to note; out xml documents were pretty small, so performance
was never an issue. Often though we just wanted to dig out and read one
unique node. Our MSXML impl. loads the whole tree regardless.

IMHO, the far better xml support form .Net is one credible argument for
moving to that platform.

"Colin Peters" <cpeters> wrote in message
news:31_6

> David Webber wrote:
>>....and I'd be interested, if anyone knows, to hear how xerces and MSXML
>>compare for ease of use?

> MSXML uses COM, so you have to get quite familiar with that... The xerces
> implementation used more abstract iterators. They worked OK, just a
> question of familiarity really.

I'll have to familiarise/refamiliarise myself with whichever I use anyway.

> One point to note; out xml documents were pretty small, so performance was
> never an issue. Often though we just wanted to dig out and read one unique
> node. Our MSXML impl. loads the whole tree regardless.

I am interested in reading and parsing MusicXML documents (defined via a
DTD) and I'll need the whole thing in memory to get what I need out of them.
So I suspect either method will be pretty memory-intensive for a long
symphony :-)

> IMHO, the far better xml support form .Net is one credible argument for
> moving to that platform.

I wondered about that. I haven't tried programming .net at all (to my
shame) though I have read a bit about it. I'm actually writing a DLL which
will be a stand-alone import filter with a specific interface of exported
"extern C" functions. I suppose I could in principle write that in managed
C++ or C++/CLI or whatever they call it these days. But that's another
learning curve on the way to my objectives :-(

Thanks for your comments - very helpful!

Dave

> I mean to get back and write some "proper code" soon, and I'd be
> interested,
> if anyone knows, to hear how xerces and MSXML compare for ease of use?

They are quite similar.

The DOM model comes with a set of standard APIs, so if you program on top
of that you are kind of shielded from details.

Both DOM and SAX are standard APIs, and if a parser claims to support them,
the experience is the same.
Xerces gives you DOM APIs (version 1, 2, 3), and also SAX (1 and 2).
I am not sure what API versions are supported by MSXML

SAX does not load the full document in memory (like DOM), so it is better
for huge documents, but then you have to keep some context info yourself,
which can get messy for complex documents.

So I would say: try to get familiar with the DOM and SAX programming models.

In my experience:
- cross-platform (Xerces++, MSXML--)
- not COM (Xerces++, MSXML--)
- validating parsers (using dtd or schemas) (Xerces++, MSXML++)
- transformations (Xerces--, MSXML++)
- XPath (Xerces--, MSXML ??)

For Xerces transformations you can use Xalan (nice), for XPath you can
use Pathan (I don't like it, outdated and clunky)

> - XPath (Xerces--, MSXML ??)

Xerces 3.0.0 is out.
It (finally) supports XPath (ver 1 and 2).

In article <Xns9B88C0460F075MihaiN>, "Mihai N." <nmihai_year_2000> wrote:
>> I mean to get back and write some "proper code" soon, and I'd be
>> interested,
>> if anyone knows, to hear how xerces and MSXML compare for ease of use?
>
>They are quite similar.
>
>The DOM model comes with a set of standard APIs, so if you program on top
>of that you are kind of shielded from details.

And loose TONS on performance.

Look at Akara and 4Suite. It is Python based, but it is much
better in terms of performance.

When you have to process hundreds of thousands of articles,
the difference could be measured in times, not percentage
points.

Sorry, I have to go now.
[..]

"Mihai N." <nmihai_year_2000> wrote in message
news:hain

>> I mean to get back and write some "proper code" soon, and I'd be
>> interested,
>> if anyone knows, to hear how xerces and MSXML compare for ease of use?
>
> They are quite similar.
>
> The DOM model comes with a set of standard APIs, so if you program on top
> of that you are kind of shielded from details.

Ok - that makes sense.

> Both DOM and SAX are standard APIs, and if a parser claims to support
> them,
> the experience is the same.
> Xerces gives you DOM APIs (version 1, 2, 3), and also SAX (1 and 2).
> I am not sure what API versions are supported by MSXML

I was using MSXML4 but I think the latest is MSXML6 which (i think) supports
version 3.

> SAX does not load the full document in memory (like DOM), so it is better
> for huge documents, but then you have to keep some context info yourself,
> which can get messy for complex documents.

As a saxophone player I couldn't resist trying SAX first <g> but the
documents I'm reading do not parse very easily starting at the beginning and
working through looking only at neighbouring items, so I needed the DOM.
(In any event I am only converting documents to my program's native format,
and so once that is done the whole XML bit can be thrown away.)

> So I would say: try to get familiar with the DOM and SAX programming
> models.

Yes - that was essentially what I did when I did my little test project with
MSXML. It's good to realise that it will transfer to Xerces if necessary.

> In my experience:
> - cross-platform (Xerces++, MSXML--)
> - not COM (Xerces++, MSXML--)
> - validating parsers (using dtd or schemas) (Xerces++, MSXML++)
> - transformations (Xerces--, MSXML++)
> - XPath (Xerces--, MSXML ??)
>
> For Xerces transformations you can use Xalan (nice), for XPath you can
> use Pathan (I don't like it, outdated and clunky)

Thanks - that is a very useful summary!

I had a glimpse of the idea that I may need transformations before I'm
finished with this, so maybe that points to continuing with MSXML (though I
don't particularly like COM.)

The other question for me is ease redistribution of the relevant modules.

(BTW one problem that I haven't yet solved is the DTD. The documents I'm
reading come with a reference to the DTD on some remote web site and if the
program could not connect to that, for any reason, to validate the document,
it was a show stopper. I didn't find any obvious way round that in MSXML,
but surely there must be one!)

Dave

> And loose TONS on performance.
>
> Look at Akara and 4Suite. It is Python based, but it is much
> better in terms of performance.
>
> When you have to process hundreds of thousands of articles,
> the difference could be measured in times, not percentage
> points.

I have no experience with 4Suite, but at the first glance
"4Suite's XML parsing capabilities are provided by Expat."
Add to this the (miserable) support for Unicode in Python
and you don't get a winning combination if your articles
need any kind of international support.

My experience with Expat:
- it is not a validating processor
- it is just a parser (cannot write)
- does not handle encodings properly
- has no clue about schemas or DTDs
(you get "events" for declarations, but they are not processed in any way)
- totaly non-standard (SAX/DOM/XPath, schemas, DTDs), although there
are libraries adding some of that in top of it
- it is "event driven" (like SAX, but non-standard), which means you
have to come with your own way to remember the context.
(same problem as SAX)

If you would have posted this as an answer to the original question,
it would have been a great match.
But posting is as a fast jab at DOM, you are comparing
things that are not in the same class.

Now, Expat has it's uses, but it depends what you need.
It is indeed fast and small, great for a quick and dirty parsing.
But not standard and not quite reliable.

> The documents I'm
> reading come with a reference to the DTD on some remote web site and if the
> program could not connect to that, for any reason, to validate the
> document,
> it was a show stopper. I didn't find any obvious way round that in MSXML,
> but surely there must be one!)

I know a way for this in Xerces (you can register for the event and
provide your own DTD).
But I have no clue how to do this in MSXML (it does not mean it's
impossible, just that I don't know how :-)