XML Parser

Hi,

Is there any SDL XML libraries in the works or plans for any (SDL_Xml?)

I would be very interested in working on this project.

Thanks,
Casey

Yup, expat is written in C just like SDL.

Happy to help,
Stefan

Yup, expat is written in C just like SDL.

Or libxml, if you want a DOM rather than just a SAX streaming API…
But that’s basically it.On Mon, Apr 13, 2009 at 10:56 AM, Stefan Monov wrote:


http://pphaneuf.livejournal.com/

I’ve used Kyra:
http://www.grinninglizard.com/kyra/index.html
?
which has a tinyxml parser:
http://www.grinninglizard.com/tinyxml/
?
or you are thinking to build something SDL specific parser?
?
Phuoc
?
/_/_/_/_/_/_ www.huaonline.com My Homepage is my Castle— On Tue, 14/4/09, casey dunham <casey.dunham at gmail.com> wrote:

From: casey.dunham@gmail.com (casey dunham)
Subject: [SDL] XML Parser
To: sdl at lists.libsdl.org
Received: Tuesday, 14 April, 2009, 12:38 AM

Hi,

Is there any SDL XML libraries in the works or plans for any (SDL_Xml?)

I would be very interested in working on this project.

Thanks,
Casey

-----Inline Attachment Follows-----


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

  Enjoy a better web experience. Upgrade to the new Internet Explorer 8 optimised for Yahoo!7. Get it now.

Thanks for the info on the C based XML parsers. Expat I already knew about
but haven’t heard of the other ones. I have also used irrXML (
http://www.ambiera.com/irrxml/) from the irrlicht engine before but that is
C++ based.

I was thinking of a native SDL library for XML parsing. I wanted to gauge
how useful people think it would be or if the consensus would be to use one
of the ones that is already out there.

  • Casey

casey dunham wrote:

Thanks for the info on the C based XML parsers. Expat I already knew
about but haven’t heard of the other ones. I have also used irrXML
(http://www.ambiera.com/irrxml/) from the irrlicht engine before but
that is C++ based.

I was thinking of a native SDL library for XML parsing. I wanted to
gauge how useful people think it would be or if the consensus would be
to use one of the ones that is already out there.

How is it possible to have a “native SDL library for XML parsing”?
Why is it native to SDL? Wouldn’t an XML parser be an XML parser?
In what way is it ‘tied’ to SDL?

That said, I think the universe does not need yet another XML
parser. We should be doing more productive things, heh. :-)–
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia

For give me for sounding naive, but why do we need XML ‘parsers’ anyway?
What ever happened to using lex/flex and yacc/bison to parse content?

– Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20090415/f6ce0118/attachment.pgpOn Tue, Apr 14, 2009 at 08:26:10PM +0800, KHMan wrote:

casey dunham wrote:

Thanks for the info on the C based XML parsers. Expat I already knew
about but haven’t heard of the other ones. I have also used irrXML
(http://www.ambiera.com/irrxml/) from the irrlicht engine before but
that is C++ based.

I was thinking of a native SDL library for XML parsing. I wanted to
gauge how useful people think it would be or if the consensus would be
to use one of the ones that is already out there.

How is it possible to have a “native SDL library for XML parsing”? Why is
it native to SDL? Wouldn’t an XML parser be an XML parser? In what way is
it ‘tied’ to SDL?

That said, I think the universe does not need yet another XML parser. We
should be doing more productive things, heh. :slight_smile:

Of course,??you can use yacc/bison to write an XML parser. But at the end you still have to write (define) it. yacc/bison is more useful for complex language where you can define operators, instructions, calculation precedences, function calls.
?
Phuoc
?
/_/_/_/_/_/_ www.huaonline.com My Homepage is my Castle— On Wed, 15/4/09, Peter Ross wrote:

From: pross@xvid.org (Peter Ross)
Subject: Re: [SDL] XML Parser
To: “A list for developers using the SDL library. (includes SDL-announce)”
Received: Wednesday, 15 April, 2009, 7:49 AM

-----Inline Attachment Follows-----

On Tue, Apr 14, 2009 at 08:26:10PM +0800, KHMan wrote:

casey dunham wrote:

Thanks for the info on the C based XML parsers. Expat I already knew?
about but haven’t heard of the other ones. I have also used irrXML?
(http://www.ambiera.com/irrxml/) from the irrlicht engine before but?
that is C++ based.

I was thinking of a native SDL library for XML parsing. I wanted to?
gauge how useful people think it would be or if the consensus would be?
to use one of the ones that is already out there.

How is it possible to have a “native SDL library for XML parsing”? Why is
it native to SDL? Wouldn’t an XML parser be an XML parser? In what way is
it ‘tied’ to SDL?

That said, I think the universe does not need yet another XML parser. We
should be doing more productive things, heh. :slight_smile:

For give me for sounding naive, but why do we need XML ‘parsers’ anyway?
What ever happened to using lex/flex and yacc/bison to parse content?

– Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)

-----Inline Attachment Follows-----


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

  Enjoy a safer web experience. Upgrade to the new Internet Explorer 8 optimised for Yahoo!7. Get it now.

Perhaps what Peter Ross is really wondering is why we use XML at all.
Isn’t it just a meta-format, the use of which requires writing support
for particular XML DTDs?

The answer is just that XML is easier to work with for many purposes.
XML is easily extensible as you can add features to XML DTDs without
invalidating earlier versions of the DTD or XML documents implementing
those DTDs. Debugging applications which take in or put out XML is
much easier than with many other means of serializing data.

Applications that lend themselves easily to hierarchical data modeling
(which is a very common case) fit snugly in the XML world. Using XML
avoids reinventing solutions to common problems like properly handling
different character encodings and character escaping.

Transforming from one XML format to another XML format is aided by a
technology called XSLT. Since XML can represent so many different
kinds of things so well, you can build pretty powerful functionality
on top of this technology.

Of course XML has a few rough edges.

Parsing XML exercises your CPU and main memory bus a little more than
it should need to. The web has been the primary driver of XML-related
technologies, and web servers are rarely if ever bound by these two
resources. Choosing an appropriate compression technology can make a
big difference. (Disclaimer: I’ve never read any formal literature on
this, I’ve only heard this from other people.)

One of XML’s advantages is that if you find you need to edit something
by hand, it’s not that hard to do, yet XML is very tedious to actually
write by hand.

DOM-manipulating code looks more gross than it should.

CDATA attributes [2] look gross.

Where does one draw the boundary between child elements and element
attributes? Tending toward attributes makes for leaner XML, but it can
come back to bite you in the future. Could Apple’s PLIST’s [2] have
possibly looked any uglier? Isn’t PLIST XML in and of itself kind of
ironic?

One of the things most commonly expressed in XML in fact does not
lend itself to hierarchical organization, which is text formatting.
Granted that this is considered poor practice, and with good reason:
it does, however, make transforming many other rich text documents
into XHTML more complex. A common alternative to strict nesting when
reading such markup isn’t any better: I cannot tell you how many times
I’ve seen websites with unterminated extents of text/font styling
markup that cause your browser to make the rest of the page, say, bold
and italic. How irritating!

Lastly, a lot of what XML could have been is what RDF [3] actually
is and what so-called “microformats” may also bring to the table.

[1] http://en.wikipedia.org/wiki/CDATA
[2] http://www.apple.com/DTDs/PropertyList-1.0.dtd
[3] http://en.wikipedia.org/wiki/Resource_Description_FrameworkOn Tue, Apr 14, 2009 at 8:49 PM, Phuoc Can Hua wrote:

— On Wed, 15/4/09, Peter Ross wrote:

For give me for sounding naive, but why do we need XML ‘parsers’ anyway?
What ever happened to using lex/flex and yacc/bison to parse content?

Of course,??you can use yacc/bison to write an XML parser. But at the end
you still have to write (define) it. yacc/bison is more useful for complex
language where you can define operators, instructions, calculation
precedences, function calls.


http://codebad.com/

Pftt! Where does it say that flex and bison are “more useful for
complex language[s]” ? That sounds more like opinion, not fact.

Furthermore, bison doesn’t have any inherent understanding of
"operators, instructions, calculation precedences, function calls".
You, the programmer, are free to use of the output of the parser
any way you want to.

Cheers,
– Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20090415/8b2ac3c2/attachment.pgpOn Tue, Apr 14, 2009 at 05:49:36PM -0700, Phuoc Can Hua wrote:

Of course,??you can use yacc/bison to write an XML parser. But at the end you still have to write (define) it. yacc/bison is more useful for complex language where you can define operators, instructions, calculation precedences, function calls.

Peter Ross wrote:

For give me for sounding naive, but why do we need XML ‘parsers’ anyway?
What ever happened to using lex/flex and yacc/bison to parse content?

Why write the same (XML) parser over and over, when you can just use a
ready made one? I’m all for using flex/bison for a new language, but
it’s daft to reinvent the wheel for something that is already extremely
well specified, deployed and understood.

Ignoring this point completely there are also other benefits to using a
specific XML parsing library such as the footprint being smaller and
having much more targetted features. You’d struggle to get bison to
validate XML documents against a specific schema without a fair chunk of
work, for example.

Perhaps what Peter Ross is really wondering is why we use XML at all.

Bringing back the subject to game-related stuff for a bit, Collada is
XML-based, loading 3D assets from Collada files sounds like it could
be rather useful (on the OpenGL side of things, of course, not so much
for SDL itself).

On the subject at hand, from having used it, I’d say that libxml2 is a
decent C library for parsing XML, that happens to also be fairly
portable (it should be usable pretty much everywhere SDL is), so I
don’t really see a need for a “SDL_XML” or anything like that. If you
wanted to keep the footprint down, I guess you could make a simple
front end for libxml2, MSXML and the Core Foundation XML parser (in
Mac OS X), where having libxml2 support would ensure you had a
fallback for any platform, but I wouldn’t really bother, myself.On Tue, Apr 14, 2009 at 9:29 PM, Donny Viszneki <donny.viszneki at gmail.com> wrote:


http://pphaneuf.livejournal.com/

Hello !

Is there any SDL XML libraries in the works or plans for any (SDL_Xml?)

What would be the use of SDL in there ?

Have a look at minixml, it is a nice small XML library :

http://www.minixml.org/

CU

Pierre Phaneuf wrote:> On Tue, Apr 14, 2009 at 9:29 PM, Donny Viszneki <donny.viszneki at gmail.com> wrote:

Perhaps what Peter Ross is really wondering is why we use XML at all.

Bringing back the subject to game-related stuff for a bit, Collada is
XML-based, loading 3D assets from Collada files sounds like it could
be rather useful (on the OpenGL side of things, of course, not so much
for SDL itself).

Read the Collada specs again. It is positioned as a future-proof
format to store and share assets for production toolchains. IIRC,
nowhere in the specs did they address something like loading
performance. Anyone knows if any production games have their final
game assets in Collada format?

If anyone wants to ‘Collada’ their final-form game assets, gee I
really hope they know what they are doing. In the same vein,
Wesnoth does some caching. I suppose that if someone wants to use
XML, or wants to keep game assets in hundreds of files, then I
hope it’s a conscious design decision with grey cells engaged, and
they go in with their eyes open.


Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia

Read the Collada specs again. It is positioned as a future-proof format to
store and share assets for production toolchains. IIRC, nowhere in the specs
did they address something like loading performance. Anyone knows if any
production games have their final game assets in Collada format?

Loading assets isn’t exactly performance sensitive for most games,
even if it were 10x slower, it wouldn’t make much difference compared
to things like loading textures, or just the sheer seek time of hard
drives… If you’re loading models on-demand from the disk while
playing the game, maybe, but that’s not the typical case, I’d say…On Wed, Apr 15, 2009 at 12:16 PM, KHMan wrote:


http://pphaneuf.livejournal.com/

I’m not a fan of xml and I would use yaml over xml any day, especially
if something small like config settings etc. Plus the yaml c library
is pretty small ande easy to understand. But in defense of XML one
fine example of XML used for games is Kenta Cho’s bulletML which is
actually a lot of fun to play with.On Wed, Apr 15, 2009 at 9:16 AM, KHMan wrote:

Pierre Phaneuf wrote:

On Tue, Apr 14, 2009 at 9:29 PM, Donny Viszneki <donny.viszneki at gmail.com> wrote:

Perhaps what Peter Ross is really wondering is why we use XML at all.

Bringing back the subject to game-related stuff for a bit, Collada is
XML-based, loading 3D assets from Collada files sounds like it could
be rather useful (on the OpenGL side of things, of course, not so much
for SDL itself).

Read the Collada specs again. It is positioned as a future-proof format to
store and share assets for production toolchains. IIRC, nowhere in the specs
did they address something like loading performance. Anyone knows if any
production games have their final game assets in Collada format?

If anyone wants to ‘Collada’ their final-form game assets, gee I really hope
they know what they are doing. In the same vein, Wesnoth does some caching.
I suppose that if someone wants to use XML, or wants to keep game assets in
hundreds of files, then I hope it’s a conscious design decision with grey
cells engaged, and they go in with their eyes open.


Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Pierre Phaneuf wrote:> On Wed, Apr 15, 2009 at 12:16 PM, KHMan <…> wrote:

Read the Collada specs again. It is positioned as a future-proof format to
store and share assets for production toolchains. IIRC, nowhere in the specs
did they address something like loading performance. Anyone knows if any
production games have their final game assets in Collada format?

Loading assets isn’t exactly performance sensitive for most games,
even if it were 10x slower, it wouldn’t make much difference compared
to things like loading textures, or just the sheer seek time of hard
drives… If you’re loading models on-demand from the disk while
playing the game, maybe, but that’s not the typical case, I’d say…

Yeah, and for an open source project keeping things in standard
formats is probably an advantage too. Hence I don’t disagree with
what Wesnoth did. Just that my paranoia about efficiency is the
result of a twisted mind, having used a VIC-20 in the past… :wink:


Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia

If it’s for config files, I use libconfig:
http://www.hyperrealm.com/libconfig/

C/C++ bindings.

There is also SDL_Config:
http://student.agh.edu.pl/~koshmaar/SDL_Config/news.php

Never tried that however, as I got used to libconfig which I use in other (non-SDL) projects.

Whenever it comes down to loading data, or configuration, for me it is a non-issue, as it doesn’t make that much of a difference if the game or level loads in 3 seconds or 5, or 30 for good 3D games…

As long as game play performance is good and it’s worth the wait.

Pat> ----- Original Message -----

From: Pavel Dudrenov
To: A list for developers using the SDL library. (includes SDL-announce)
Sent: Wednesday, April 15, 2009 11:42:28 AM
Subject: Re: [SDL] XML Parser

I’m not a fan of xml and I would use yaml over xml any day, especially
if something small like config settings etc. Plus the yaml c library
is pretty small ande easy to understand. But in defense of XML one
fine example of XML used for games is Kenta Cho’s bulletML which is
actually a lot of fun to play with.

On Wed, Apr 15, 2009 at 9:16 AM, KHMan wrote:

Pierre Phaneuf wrote:

On Tue, Apr 14, 2009 at 9:29 PM, Donny Viszneki wrote:

Perhaps what Peter Ross is really wondering is why we use XML at all.

Bringing back the subject to game-related stuff for a bit, Collada is
XML-based, loading 3D assets from Collada files sounds like it could
be rather useful (on the OpenGL side of things, of course, not so much
for SDL itself).

Read the Collada specs again. It is positioned as a future-proof format to
store and share assets for production toolchains. IIRC, nowhere in the specs
did they address something like loading performance. Anyone knows if any
production games have their final game assets in Collada format?

If anyone wants to ‘Collada’ their final-form game assets, gee I really hope
they know what they are doing. In the same vein, Wesnoth does some caching.
I suppose that if someone wants to use XML, or wants to keep game assets in
hundreds of files, then I hope it’s a conscious design decision with grey
cells engaged, and they go in with their eyes open.


Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

And for other platforms using plain xml is not good, it can cause too
much trouble with memory fragmentation. I always prefer to use XML as
intermediate format where I will create a compiler tool for a memory
optimized binary structure.

As other alternatives, I think that the best text format for
specifying things is JSON. But there are other options like libconfig
and boost::program_options.On Wed, Apr 15, 2009 at 2:04 PM, Patryk Bratkowski wrote:

If it’s for config files, I use libconfig:
http://www.hyperrealm.com/libconfig/

C/C++ bindings.

There is also SDL_Config:
http://student.agh.edu.pl/~koshmaar/SDL_Config/news.php

Never tried that however, as I got used to libconfig which I use in other (non-SDL) projects.

Whenever it comes down to loading data, or configuration, for me it is a non-issue, as it doesn’t make that much of a difference if the game or level loads in 3 seconds or 5, or 30 for good 3D games…

As long as game play performance is good and it’s worth the wait.

Pat

----- Original Message ----

From: Pavel Dudrenov
To: A list for developers using the SDL library. (includes SDL-announce)
Sent: Wednesday, April 15, 2009 11:42:28 AM
Subject: Re: [SDL] XML Parser

I’m not a fan of xml and I would use yaml over xml any day, especially
if something small like config settings etc. Plus the yaml c library
is pretty small ande easy to understand. But in defense of XML one
fine example of XML used for games is Kenta Cho’s bulletML which is
actually a lot of fun to play with.

On Wed, Apr 15, 2009 at 9:16 AM, KHMan wrote:

Pierre Phaneuf wrote:

On Tue, Apr 14, 2009 at 9:29 PM, Donny Viszneki wrote:

Perhaps what Peter Ross is really wondering is why we use XML at all.

Bringing back the subject to game-related stuff for a bit, Collada is
XML-based, loading 3D assets from Collada files sounds like it could
be rather useful (on the OpenGL side of things, of course, not so much
for SDL itself).

Read the Collada specs again. It is positioned as a future-proof format to
store and share assets for production toolchains. IIRC, nowhere in the specs
did they address something like loading performance. Anyone knows if any
production games have their final game assets in Collada format?

If anyone wants to ‘Collada’ their final-form game assets, gee I really hope
they know what they are doing. In the same vein, Wesnoth does some caching.
I suppose that if someone wants to use XML, or wants to keep game assets in
hundreds of files, then I hope it’s a conscious design decision with grey
cells engaged, and they go in with their eyes open.


Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Animal Frontline Liberation

You’re confused. XML is not inherently a source of memory
fragmentation (you can use your own fine allocator in your XML
processing code if that’s really what you want.) What makes you think
that deserializing from JSON is less fragmenty than deserializing from
XML?On Wed, Apr 15, 2009 at 2:09 PM, fungos wrote:

And for other platforms using plain xml is not good, it can cause too
much trouble with memory fragmentation. I always prefer to use XML as
intermediate format where I will create a compiler tool for a memory
optimized binary structure.

As other alternatives, I think that the best text format for
specifying things is JSON. But there are other options like libconfig
and boost::program_options.


http://codebad.com/