Thread: RE: XML was RE: [GD-General] RE: A portable preferences library
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-general
|
From: Paul B. <pa...@mi...> - 2003-12-16 04:20:46
|
We ended up using a ton of Xpath query expressions in a number of places throughout development. We had a simple commandline tool called 'xq' that allowed our designers to run xpath queries against data. We also used a number of languages (Perl, Python, .net stuff, etc...) for our tools. Sure, you can parse INI files in all of those languages but we didn't have to write any code as it was. Finally, we used XML Schema for external data validation. While it didn't do semantic validation, things like Schematron might have been interesting there. There were other advantages but interop (in lots of forms) was the most useful. =20 > -----Original Message----- > From: gam...@li...=20 > [mailto:gam...@li...] On=20 > Behalf Of Brian Hook > Sent: Monday, December 15, 2003 10:14 PM > To: gam...@li... > Subject: XML was RE: [GD-General] RE: A portable preferences library >=20 > This list server is getting more and more flakey...anyway,=20 > this is a repost since my prior one evidently went into the=20 > great void.. >=20 > > Behalf Of Jeff Laing > > I'm surprised that no-one has said "use XML format please"=20 > - its not=20 > > that painful, given that you'll have a fairly limited schema to=20 > > implement. >=20 > So here's a question -- I know that whenever a discussion=20 > about text file formats comes up there is often a "use XML"=20 > grenade tossed into it. Now, I can think of a lot of reasons=20 > NOT to use XML (i.e. it's overkill, for one), but I'm curious=20 > what real, tangible reasons for using XML exist, as opposed=20 > to a simple application specific structure (like INI files). >=20 > Brian >=20 |
|
From: Gareth L. <GL...@cl...> - 2003-12-16 12:25:39
|
Hopefully you aren't building a mesh from that at run time ? XML is good, XML is great. But please tell me that you aren't considering having mullion polygon meshes in text format ready to be parsed at runtime ? On a side note, those of you with the 'luck' to work on pc games, you can just use the msxml parser, which is pretty fully featured. > -----Original Message----- > From: Jorrit Tyberghein [mailto:Jor...@uz...] > Sent: 16 December 2003 12:14 > To: gam...@li... > Subject: Re: XML was RE: [GD-General] RE: A portable > preferences library > > > Alen Ladavac wrote: > > >>We use XML a lot in Crystal Space (http://crystal.sf.net). > It does tend > >>to give very > >>big files but we also found that it doesn't matter. > >> > >> > > > >Just how big that is? Can you please compare size of a mesh > in XML format to > >the same mesh in, say, .3ds or .lwo? > > > > > I didn't make the map files so I don't have any of the model > files that > were used but I can show you an example of a simple mesh in CS: > > <meshobj name="cube"> > <plugin>thing</plugin> > <params> > <v x="-1" y="0" z="1" /> > <v x="0" y="0" z="1" /> > ... (more vertices follow) > <material>brick</material> > <p> <v>0</v> <v>1</v> <v>2</v> </p> > <p> <v>3</v> <v>2</v> <v>4</v> <v>5</v> </p> > ... (more polygons follow) > </params> > </meshobj> > > So this is indeed pretty verbose. > > > > > > >>CS supports reading > >>from ZIP files > >>so map files are usually placed in compressed archives. XML > compresses very > >>well (due to the high redundancy) so the size disadvantage > nearly completely > >>disappears in that case. > >> > >> > > > >Can you also please compare size of a zipped XML mesh and a > zipped .3ds, or > >.lwo or similar format of the same mesh? > > > > > Sorry. Don't have the needed models to do that. > > >Also, in case that zipping really does remove the redundancy > well enough to > >allow us to ignore the size difference, did you check your > effective loading > >throughput? Meaning how much MB/sec can you read from the > disk. To make sure > >that the parser is not slowing your loading. Ideally, you > should be limited by > >the transfer rate of the disk, not by the CPU. > > > > > The PlaneShift game (made with CS) has about 25 megabytes > (uncompressed) > of XML files (aggregated > in four big files) of level data. On my Linux system at home > (an Athlon > XP2000) the levels load > in about 16-20 seconds. That includes the following operations: > - Extracting the XML data from the ZIP. > - Parsing of XML. > - Creation of all objects. > - Loading of all textures used in the levels and > preparing them for > use with OpenGL. > - Creation of the kdtree for the visibility culler. > - Loading of the lightmap data for the 100000 polygons > that are in > those levels. > - Creation of oriented bounding boxes for collision > detection (this > is the most > time consuming operation of all things mentioned here). > > I don't have seperate numbers for XML parsing but it is a relatively > small part > of the entire thing. Of course this is done using a hand-made > XML parser > which > is very lean and mean and is optimized specifically towards reading. > > Greetings, > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=557 > |
|
From: Jorrit T. <Jor...@uz...> - 2003-12-16 12:29:39
|
Gareth Lewin wrote: >Hopefully you aren't building a mesh from that at run time ? > >XML is good, XML is great. But please tell me that you aren't considering >having mullion polygon meshes in text format ready to be parsed at runtime ? > > Well they are parsed at load time. But it all goes very fast (as my mail below shows). We have no performance problems at all related to XML. The XML parsing is only a fraction of the total cost. Greetings, |
|
From: Gareth L. <GL...@cl...> - 2003-12-16 12:35:51
|
> We have no performance problems at all related to XML. The > XML parsing > is only a fraction > of the total cost. > The total cost of what ? Game data files should be stored (in the final form) in a form that requires as little parsing as possible. This makes level loading significatly faster, reduces memory overhead (you have to start pre-caching earlier) etc etc. |
|
From: Jorrit T. <Jor...@uz...> - 2003-12-16 12:40:32
|
Gareth Lewin wrote: >>We have no performance problems at all related to XML. The >>XML parsing >>is only a fraction >>of the total cost. >> >> >> > >The total cost of what ? > Of game loading. i.e. XML parsing is negligable compared to all the rest that has to be done. > Game data files should be stored (in the final >form) in a form that requires as little parsing as possible. This makes >level loading significatly faster, reduces memory overhead (you have to >start pre-caching earlier) etc etc. > > Well that means we have to duplicate all loader code which is something we are not going to do. This approach is much nicer. However, CS does support binary XML though. This doesn't appear to give a lot of benefit so we don't use it by default. Greetings, |
|
From: Gareth L. <GL...@cl...> - 2003-12-16 12:39:02
|
Ok, I missed the following bit from your first email
-------------
The PlaneShift game (made with CS) has about 25 megabytes (uncompressed)
of XML files (aggregated
in four big files) of level data. On my Linux system at home (an Athlon
XP2000) the levels load
in about 16-20 seconds. That includes the following operations:
- Extracting the XML data from the ZIP.
- Parsing of XML.
- Creation of all objects.
- Loading of all textures used in the levels and preparing them for
use with OpenGL.
- Creation of the kdtree for the visibility culler.
- Loading of the lightmap data for the 100000 polygons that are in
those levels.
- Creation of oriented bounding boxes for collision detection (this
is the most
-------------
You write that as if it's a positive. Surely if the data was binary packed,
with the textures prepared for your renderer, the kdtree preproccesed, the
lightmap data stored with the polygons and the oriented bounding boxes
precalculated you could just do
----------
- Extracting the data from the ZIP.
- Loading of all textures used in the levels
----------
None of those steps change without the level changing, so why waste all that
time. 16-20 seconds is a hell of a long for a level to load when you could
do 16(guestimate) of those seconds offline.
> -----Original Message-----
> From: Jorrit Tyberghein [mailto:Jor...@uz...]
> Sent: 16 December 2003 12:29
> To: gam...@li...
> Subject: Re: XML was RE: [GD-General] RE: A portable
> preferences library
>
>
> Gareth Lewin wrote:
>
> >Hopefully you aren't building a mesh from that at run time ?
> >
> >XML is good, XML is great. But please tell me that you
> aren't considering
> >having mullion polygon meshes in text format ready to be
> parsed at runtime ?
> >
> >
> Well they are parsed at load time. But it all goes very fast
> (as my mail
> below shows).
> We have no performance problems at all related to XML. The
> XML parsing
> is only a fraction
> of the total cost.
>
> Greetings,
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive? Does it
> help you create better code? SHARE THE LOVE, and help us help
> YOU! Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>
|
|
From: Jorrit T. <Jor...@uz...> - 2003-12-16 13:15:41
|
Gareth Lewin wrote: >None of those steps change without the level changing, so why waste all that >time. 16-20 seconds is a hell of a long for a level to load when you could >do 16(guestimate) of those seconds offline. > > This would be possible but it would severely compromize the object oriented design of CS. Performance is more than adequate IMHO so why compromize proper design in order to get more? Greetings, |
|
From: Ivan-Assen I. <as...@ha...> - 2003-12-16 13:20:09
|
> >None of those steps change without the level changing, so > why waste all that > >time. 16-20 seconds is a hell of a long for a level to load > when you could > >do 16(guestimate) of those seconds offline. > > > > > This would be possible but it would severely compromize the object oriented design > of CS. Performance is more than adequate IMHO so why compromize proper > design in order to get more? I second Gareth here. 16-20 seconds is NOT adequate level load time on a reasonably modern PC. You shouldn't ever do load-time anything that can do level-export-time. This doesn't contradict with nice OO design, and if you feel like "duplicating" code if you shift parsing and preprocessing to the tools, maybe you should use the more politically correct word "reuse". |
|
From: Jorrit T. <Jor...@uz...> - 2003-12-16 13:28:55
|
Ivan-Assen Ivanov wrote: > I second Gareth here. 16-20 seconds is NOT adequate level load time on > >a reasonably modern PC. You shouldn't ever do load-time anything that >can do level-export-time. This doesn't contradict with nice OO design, and >if you feel like "duplicating" code if you shift parsing and preprocessing to the >tools, maybe you should use the more politically correct word "reuse". > > These are REALLY big levels we are talking about here. i.e. 100000 polygons (each with lightmap data) and then about 50000 triangle meshes (seperate from that). Most modern games that I know don't try to load that many game data at once (most use dynamic loading to load what they need later). Greetings, |
|
From: Jorrit T. <Jor...@uz...> - 2003-12-16 13:34:41
|
Ivan-Assen Ivanov wrote: > I second Gareth here. 16-20 seconds is NOT adequate level load time on > >a reasonably modern PC. You shouldn't ever do load-time anything that >can do level-export-time. This doesn't contradict with nice OO design, and >if you feel like "duplicating" code if you shift parsing and preprocessing to the >tools, maybe you should use the more politically correct word "reuse". > > > There is also another issue why I don't do this. It takes a lot of time to make this optimized loader (although possible). I think there are a lot more important things to do. Optimzing speed at runtime for example. We have only so much free time :-) Greetings, |
|
From: Richard S. <Ric...@ei...> - 2003-12-16 12:39:35
|
> > 1. Because developers are already using XML and have since thrown > > away, forgotten or don't want to write a parser. > Just curious, what is the footprint of the XML parser you are=20 > using? I know > some that are like >3MB of binary code. That stuff gives me=20 > the creeps. Perhaps you have some lightweight one? There are parsers to suit all needs. The largest fully validation parsers with spoinks and added wurlitsers are in the couple of meg=20 area. Micro parsers with no valdation can be as small as a couple of=20 K. A quick google showed a large number of XML parsers which claimed to be small and fast. Several were open source. I'm pretty sure it would be easy to find one that suits. > Also, what kind of info are you people storing in XML files?=20 > I often hear > comments about how XML is so great that we should store=20 > everything in it. Ah, no :*) People who say that tend to be application programmers or web monkeys, where size of data or speed of parsing tends to be less important. XML shouod be used to store data where the=20 format gives it lots of added value. Broadly speaking (very broadly) XML is going to be of much more use to AI programmers, gameplay programmers and designers. I'm not a graphics programmer, but I can't really see a case where=20 it would be any good for holding data about vertices, or any other graphics data, as someone asked elsewhere in the thread. However, for holding game object initialisation data for a component based system, it is a godsend. For representing game rules or formulae, it is extremely effective. Entire game AI can be represented, whether it be a state based system, a rules based system, goal orientated or emergent. The entire system can be expressed in validated XML allowing designers to modify any element to their hearts content. It ensure syntax safety so they can't break anything. You can also use it to enforce symantic safety though generally I'd prefer to do that in code. XML is there to provide us the mechanism for giving them this data=20 driven architecture they keep saying they want. It's certainly not there to give us a better way of representing our graphics data. > Alen Rich |
|
From: Gareth L. <GL...@cl...> - 2003-12-16 12:42:50
|
> > > 1. Because developers are already using XML and have since thrown > > > away, forgotten or don't want to write a parser. > > Just curious, what is the footprint of the XML parser you are > > using? I know > > some that are like >3MB of binary code. That stuff gives me > > the creeps. Perhaps you have some lightweight one? > > There are parsers to suit all needs. The largest fully validation > parsers with spoinks and added wurlitsers are in the couple of meg > area. Micro parsers with no valdation can be as small as a couple of > K. The most fancy on the PC is msxml, it doesn't everything, .NET basically uses it. The smallest I know is CMarkup (search for it on Codeproject). it's literally a single class of C++ code, it's smaller than a few k :) |
|
From: Ivan-Assen I. <as...@ha...> - 2003-12-16 13:10:49
|
> The most fancy on the PC is msxml, it doesn't everything, .NET basically > uses it. Actually, I remember reading an article comparing the performance of MSXML (used via COM interop) with the .NET XML classes, so I believe they are different. The .NET classes are written in C# (and are a bit slower). About vertex data: we have a dual-pass data processing scheme, where first a simple dumb Max plugin dumps all the data Max provides into a verbose format. The second pass reads the raw vertex data, builds meshes, optimizes, etc. and prepares single-seek binary files. It is convenient to separate the flaky DLL-hell Max SDK part from the part the does the real work. In such a scenario, I believe it's OK to use XML for the first format. Maybe when the assets grow to be in the order of hundreds or thousands of meshes, it will show on the build time. I'll repeat myself and say Infopath adds a whole new dimension of usefullness to XML. If you think IE showing XMLs color-coded and collapsible, or even with a custom stylesheet, is cool, imagine building a sensible user interface for editing complex structures, with validation, in hours not days. |
|
From: Gareth L. <GL...@cl...> - 2003-12-16 12:44:21
|
> The most fancy on the PC is msxml, it doesn't everything, of course I mean 'it does everything' |
|
From: Richard S. <Ric...@ei...> - 2003-12-16 12:54:18
|
> The most fancy on the PC is msxml, it doesn't everything,=20 > .NET basically uses it. Currently no parsers implement the entire set of standards as=20 they are still being written. However, I would recommend Apache's XercesC over msxml. Technical reasons include that Xerces properly implements the open standard in an opensource manner. Xerces has a much faster uptake time of standards additions. MS have a habit of adding unecessary proprietry extensions to their implementations of standards which locks you in to their implementation. > The smallest I know is CMarkup (search for it on Codeproject). it's > literally a single class of C++ code, it's smaller than a few k :) The smallest I know is mine which is the release time parser (debug parser is fully validating XercesC) and it's a single class and fills maybe 2 code pages (not including documentation, 1280*1024 resolution, full size MSVC editor window). XML really is that easy to write straight parsers for. Rich |
|
From: Ivan-Assen I. <as...@ha...> - 2003-12-16 13:13:58
|
> Technical reasons include that Xerces properly > implements the open standard in an opensource manner. This is a political reason, not a technical reason. I wouldn't base the choice of including a bloated mess of dozens of source files over a couple of lines of COM calls, on what is a proper opensource manner, or what habits MS has. It's a matter of engineering, not Slashdot karma. |
|
From: J C L. <cl...@ka...> - 2003-12-16 14:59:08
|
On Tue, 16 Dec 2003 15:13:52 +0200 Ivan-Assen Ivanov <as...@ha...> wrote: >> Technical reasons include that Xerces properly implements the open >> standard in an opensource manner. > This is a political reason, not a technical reason. It is both, mixed. > I wouldn't base the choice of including a bloated mess of dozens of > source files over a couple of lines of COM calls, on what is a proper > opensource manner, or what habits MS has. It's a matter of > engineering, not Slashdot karma. As he stated, Xerces also implements the current draft to a degree that is auditable and published, and is therefore largely without surprises. This is a technical benefit, both in the certainty of what is supported and how, and the adherence to standards and thus interop with other adherent tools. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. cl...@ka... He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. |
|
From: Richard S. <Ric...@ei...> - 2003-12-16 13:27:58
|
> > Technical reasons include that Xerces properly > > implements the open standard in an opensource manner.=20 > This is a political reason, not a technical reason. I=20 > wouldn't base the choice > of including a bloated mess of dozens of source files over a=20 > couple of lines of COM calls, > on what is a proper opensource manner, or what habits MS has.=20 > It's a matter of engineering, not Slashdot karma. Using open standards and open source is a technical decision as well as a political one. If you do not agree with the technical benefits if such an approach, that's fine, but it does not invalidate them. Saying that all open source implementations of an XML parser are 'bloated messes' is highly prejorative and demonstrably wrong. I would suggest that an Apache implementation of an XML parser is more likely to be fast and effective than an MS one, because they have some thousands of developers looking over their shoulder. A benefit MS does not have. To include 'a couple of lines of COM calls' as a complete use of an XML parser fails to account for the unmeasurable costs of using a system which you cannot profile, let alone modify, which is designed to cover a multitude of sins as opposed to the relatively small number needed for a given application. This is a matter of engineering. There are notable technical advantages of using an open source standardised solution over using a closed=20 proprietry one. I'm not entirely sure how you can think otherwise. Rich |
|
From: Ivan-Assen I. <as...@ha...> - 2003-12-16 13:41:20
|
> Saying that all open source implementations of an XML parser > are 'bloated messes' is highly prejorative and demonstrably wrong. Not all; I was saying that Xerces, last time I checked it, was a bloated mess. > I would suggest that an Apache implementation of an XML parser > is more likely to be fast and effective than an MS one, because > they have some thousands of developers looking over their shoulder. > A benefit MS does not have. To the contrary. MS does have thousands of developers in-house, a lot of them depending on the quality of the XML parser. Microsoft has a very well developed system for internal communications, so I wouldn't be suprised if developers of core components like MSXML get the same, if not greater feedback than open source projects. > To include 'a couple of lines of COM calls' as a complete use of > an XML parser fails to account for the unmeasurable costs of using > a system which you cannot profile, let alone modify, which is designed > to cover a multitude of sins as opposed to the relatively small number > needed for a given application. The choice of XML is first and foremost based on convenience, not performance. As others have pointed out besides me, you should convert to binary formats for runtime loading. > This is a matter of engineering. There are notable technical advantages > of using an open source standardised solution over using a closed > proprietry one. Xerces isn't any more "standardised" than MSXML - both are implementations of the XML standard, but there is no "standard implementation". Both conform to the subset of the XML standards we need. By the way, we use expat in some of our projects - and we've never used it as anything as a black box. It works, and it works well. We never used its "open-sourceness". We wrapped it with a thin layer to feel more natural to use from our code (coding conventions, storage issues etc.) It could have been MSXML just as well. |
|
From: Paul B. <pa...@mi...> - 2003-12-16 13:35:19
|
The .NET System.Xml code is not based on the MSXML parser. They are different codebases and handle different standards differently. > -----Original Message----- > From: gam...@li...=20 > [mailto:gam...@li...] On=20 > Behalf Of Gareth Lewin > Sent: Tuesday, December 16, 2003 6:40 AM > To: gam...@li... > Subject: RE: XML was RE: [GD-General] RE: A portable=20 > preferences library >=20 > > > > 1. Because developers are already using XML and have=20 > since thrown > > > > away, forgotten or don't want to write a parser. > > > Just curious, what is the footprint of the XML parser you are=20 > > > using? I know > > > some that are like >3MB of binary code. That stuff gives me=20 > > > the creeps. Perhaps you have some lightweight one? > >=20 > > There are parsers to suit all needs. The largest fully validation > > parsers with spoinks and added wurlitsers are in the couple of meg=20 > > area. Micro parsers with no valdation can be as small as a=20 > couple of=20 > > K. >=20 > The most fancy on the PC is msxml, it doesn't everything,=20 > .NET basically > uses it. > The smallest I know is CMarkup (search for it on Codeproject). it's > literally a single class of C++ code, it's smaller than a few k :) >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D557 >=20 >=20 |
|
From: Richard S. <Ric...@ei...> - 2003-12-16 14:10:17
|
> I'll repeat myself and say Infopath adds a whole new=20 > dimension of usefullness > to XML. If you think IE showing XMLs color-coded and collapsible, > or even with a custom stylesheet, is cool, imagine building a sensible > user interface for editing complex structures, with=20 > validation, in hours not days.=20 I did go and take a look, but there was no downloadable trial, and I don't want to wait for MS to post me a CD from the US. They did provide an interactive demo, which was in fact just someone trying to tell me how great it was without actually telling me what it did. Score one for marketing, nill for development. It seemed to me that it provided a way to lay out a GUI to allow data input to static XML. One requirement we have is that on selecting a piece of data, the GUI changes to show a set of possible choices. Essneitally, we want the GUI to guide the designer into using the correct data structure. Is this what InfoPath is supposed to do? Does it dynamically change the GUI depending on current choices? Or is it static forms of data which represent an instance of the data the XML represents? Alternatively, is there way of downloading the trial version? Rich |
|
From: Ivan-Assen I. <as...@ha...> - 2003-12-16 14:26:46
|
> It seemed to me that it provided a way to lay out a GUI to allow > data input to static XML. One requirement we have is that on selecting > a piece of data, the GUI changes to show a set of possible choices. > Essneitally, we want the GUI to guide the designer into using the > correct data structure. > > Is this what InfoPath is supposed to do? Does it dynamically change > the GUI depending on current choices? Or is it static forms of > data which represent an instance of the data the XML represents? It is very easy to do - you can hide/show or reformat (font/colors etc.) controls or groups of controls based on the values of other controls. It has the concept of repeatable sections, which can be displayed as series of identical grouped controls, or tables, and the user can insert/delete sections. You can perform simple validation with GUI-edited rules, or more complex validation and event processing with JScript. Of course, it's not perfect - I'm waiting to see the fabled version 3.0 - but it's a great step up from grid-based editors like XMLSpy. |
|
From: Gareth L. <GL...@cl...> - 2003-12-16 14:16:13
|
> Actually, I remember reading an article comparing the performance of > MSXML (used via COM interop) with the .NET XML classes, so I > believe they > are different. The .NET classes are written in C# (and are a > bit slower). > > About vertex data: we have a dual-pass data processing scheme, where > first a simple dumb Max plugin dumps all the data Max > provides into a verbose > format. The second pass reads the raw vertex data, builds meshes, > optimizes, etc. and prepares single-seek binary files. It is > convenient to > separate the flaky DLL-hell Max SDK part from the part the > does the real work. > > In such a scenario, I believe it's OK to use XML for the first format. > Maybe when the assets grow to be in the order of hundreds or thousands > of meshes, it will show on the build time. > I totally agree with you here. Intermeditry formats are very good. Not only to get around the max DLL crap, but also so you can write exporters from various tools to the same format, and write tools that load the xml up, modify the data (stripify, build bsd trees, whatever) and write out the xml again. But single seek files, preferably ones that can be read directly into memory, are (to me) a must for games. |
|
From: Gareth L. <GL...@cl...> - 2003-12-16 14:18:59
|
> > The most fancy on the PC is msxml, it doesn't everything, > > .NET basically uses it. > > Currently no parsers implement the entire set of standards as > they are still being written. So ? msxml is pretty fully featured for what we were discussing. > However, I would recommend Apache's > XercesC over msxml. Technical reasons include that Xerces properly > implements the open standard in an opensource manner. Xerces has > a much faster uptake time of standards additions. MS have a habit of > adding unecessary proprietry extensions to their implementations of > standards which locks you in to their implementation. How is that valid ? That's the same opengl/directx linux/windows type argument. In what way is it related or productive to the discussion ? I prefer msxml mainly because everyone with IE6 on their machine has it, less to download. And Xerces (admittedly I haven't tried it in 2 years) had an awful interface and terrible documentation. I prefer expat if you want open source. > > > The smallest I know is CMarkup (search for it on Codeproject). it's > > literally a single class of C++ code, it's smaller than a few k :) > > The smallest I know is mine which is the release time parser (debug > parser is fully validating XercesC) and it's a single class and > fills maybe 2 code pages (not including documentation, 1280*1024 > resolution, full size MSVC editor window). XML really is that easy > to write straight parsers for. Well as yours isn't downloadable and CMarkup is, I'll stick with CMarkup. |
|
From: Eero P. <epa...@ko...> - 2003-12-16 16:31:11
|
Gareth Lewin wrote: > How is that valid ? That's the same opengl/directx linux/windows type > argument. In what way is it related or productive to the discussion ? I > prefer msxml mainly because everyone with IE6 on their machine has it, less > to download. And Xerces (admittedly I haven't tried it in 2 years) had an There are of course different versions of msxml, just installed one software which required me to fetch an update from Microsoft. (the software was actually clever enough to automatically download it, except that it was not clever enough to do the download for non English localized WindowsXP, and I think the required download package is not that clearly named on Microsoft site...) Eero |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X