From davidson_jeff at yahoo.com Tue Jun 3 16:31:00 2003 From: davidson_jeff at yahoo.com (jeff davidson) Date: Tue Jun 3 18:31:03 2003 Subject: [Expat-discuss] infinite document size? Message-ID: <20030603223100.31792.qmail@web20806.mail.yahoo.com> Hi, I have written a server which receives and parses xml messages using expat. It seems to me that I may be able to create my handlers, receive an infinite number of messages and, when the program exits (which will hopefully be never), I can free the parser. Is that the case? Do other people use expat in this manner? Or is it safer to free the parser after each message received? thanks, jd __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com From karl at waclawek.net Tue Jun 3 20:46:18 2003 From: karl at waclawek.net (Karl Waclawek) Date: Tue Jun 3 19:44:44 2003 Subject: [Expat-discuss] infinite document size? References: <20030603223100.31792.qmail@web20806.mail.yahoo.com> Message-ID: <000a01c32a2a$547ac1b0$0207a8c0@karl> > I have written a server which receives and parses > xml messages using expat. It seems to me that I may be > able to create my handlers, receive an infinite number > of messages and, when the program exits (which will > hopefully be never), I can free the parser. Is that > the case? Do other people use expat in this manner? Is each message a complete XML document? > Or is it safer to free the parser after each message > received? If the answer to the above question is Yes, then the XML_ParserReset function is specifically intended for this purpose. So you should be able to use it instead of XML_ParserFree. Karl From derek at bluegenesis.com Wed Jun 11 14:41:35 2003 From: derek at bluegenesis.com (Derek Snider) Date: Wed Jun 11 13:35:49 2003 Subject: [Expat-discuss] Nested calls to XML_Parse Message-ID: <0e4d01c33040$b487ba60$4d01a8c0@devnull.hostopia.com> Why do nested calls to XML_Parse (i.e. calling XML_Parse from within an element handler) end up putting the parser into an endless loop? I don't mean code-wise why the library acts this way, but why is this the intention? Is it not reasonable to want the possibility of XML elements expanding into more XML to be passed to the parser? It seems to add a lot of unneccessary overhead to require that nested parsing involve nested creation and freeing of additional parsers (the only way I could get this to work). Am I missing something? From Greg.Martin at TELUS.COM Wed Jun 11 13:40:15 2003 From: Greg.Martin at TELUS.COM (Greg Martin) Date: Wed Jun 11 15:40:23 2003 Subject: [Expat-discuss] Nested calls to XML_Parse Message-ID: Expat is a stream oriented parser. It seems to me (as a bystander using the API) that it wouldn't make sense to embed a call to XML_Parse. You're not starting a new document you are simply parsing embedded tags and that's what your callback functions handle. A call to XML_Parse probably resets the state of the parser or the stream position(and hence your loop). I suppose if the contents of a tag was another xml document you could create a second parser object and call XML_Parse using that parser ... Regards, Greg. -----Original Message----- From: Derek Snider [mailto:derek@bluegenesis.com] Sent: Wednesday, June 11, 2003 11:42 AM To: expat-discuss@libexpat.org Subject: [Expat-discuss] Nested calls to XML_Parse Why do nested calls to XML_Parse (i.e. calling XML_Parse from within an element handler) end up putting the parser into an endless loop? I don't mean code-wise why the library acts this way, but why is this the intention? Is it not reasonable to want the possibility of XML elements expanding into more XML to be passed to the parser? It seems to add a lot of unneccessary overhead to require that nested parsing involve nested creation and freeing of additional parsers (the only way I could get this to work). Am I missing something? _______________________________________________ Expat-discuss mailing list Expat-discuss@libexpat.org http://mail.libexpat.org/mailman/listinfo/expat-discuss From derek at bluegenesis.com Wed Jun 11 17:54:32 2003 From: derek at bluegenesis.com (Derek Snider) Date: Wed Jun 11 16:48:45 2003 Subject: [Expat-discuss] Nested calls to XML_Parse In-Reply-To: Message-ID: <0e7701c3305b$a89685e0$4d01a8c0@devnull.hostopia.com> It may not "make sense" to embed a call to XML_Parse, but it certainly can be useful if you want to have XML elements which generate dynamic XML content. I went the route of creating a second parser, but XML_Parse should be robust enough to properly handle being called by an element handler. It already supports appending data to the buffer (note the isFinal flag), why not inserting data at the current point of parsing? > -----Original Message----- > From: Greg Martin [mailto:Greg.Martin@telus.com] > Sent: June 11, 2003 3:40 PM > To: Derek Snider; expat-discuss@libexpat.org > Subject: RE: [Expat-discuss] Nested calls to XML_Parse > > > Expat is a stream oriented parser. It seems to me (as a > bystander using the API) that it wouldn't make sense to embed > a call to XML_Parse. You're not starting a new document you > are simply parsing embedded tags and that's what your > callback functions handle. A call to XML_Parse probably > resets the state of the parser or the stream position(and > hence your loop). I suppose if the contents of a tag was > another xml document you could create a second parser object > and call XML_Parse using that parser ... Regards, Greg. > > -----Original Message----- > From: Derek Snider [mailto:derek@bluegenesis.com] > Sent: Wednesday, June 11, 2003 11:42 AM > To: expat-discuss@libexpat.org > Subject: [Expat-discuss] Nested calls to XML_Parse > > > Why do nested calls to XML_Parse (i.e. calling XML_Parse from > within an element handler) end up putting the parser into an > endless loop? > > I don't mean code-wise why the library acts this way, but why > is this the intention? > > Is it not reasonable to want the possibility of XML elements > expanding into more XML to be passed to the parser? > > It seems to add a lot of unneccessary overhead to require > that nested parsing involve nested creation and freeing of > additional parsers (the only way I could get this to work). > > Am I missing something? From karl at waclawek.net Wed Jun 11 18:02:12 2003 From: karl at waclawek.net (Karl Waclawek) Date: Wed Jun 11 17:02:31 2003 Subject: [Expat-discuss] Nested calls to XML_Parse References: <0e7701c3305b$a89685e0$4d01a8c0@devnull.hostopia.com> Message-ID: <012401c3305c$bb1f9700$9e539696@citkwaclaww2k> > It may not "make sense" to embed a call to XML_Parse, but it certainly > can be useful if you want to have XML elements which generate dynamic > XML content. > > I went the route of creating a second parser, but XML_Parse should be > robust enough to properly handle being called by an element handler. It is documented not to be called recursively - so it is as robust as designed. > It > already supports appending data to the buffer (note the isFinal flag), > why not inserting data at the current point of parsing? Because a recursive call requires some kind of stack storage structure which it doesn't have. The proper way of inserting content at specific points in an XML document is through entity references. Even then the external entity ref handler needs to create a new parser instance (special kind, which inherits context) to parse that entity. In any case, if you would not have to create a new parser instance, the parser would have to do something equivalent anyway, so nothing much would be gained. Karl From dr at netscape.com Wed Jun 11 15:25:29 2003 From: dr at netscape.com (Dan Rosen) Date: Wed Jun 11 17:28:15 2003 Subject: [Expat-discuss] Nested calls to XML_Parse In-Reply-To: <0e7701c3305b$a89685e0$4d01a8c0@devnull.hostopia.com> References: <0e7701c3305b$a89685e0$4d01a8c0@devnull.hostopia.com> Message-ID: <3EE79E49.9020302@netscape.com> Hi Derek, There is an important conceptual distinction here between what you want to do and what a parser does. Any parser's role is simply to parse serialized data into a programmatic representation of that data, regardless of the type of data or its representation. What you're trying to do transcends parsing, and falls squarely into the domain of data transformation and processing. In the process of parsing, it is not appropriate (or is, at least, very unorthodox) to modify the data stream being parsed. Allowing this essentially turns a decidable problem for which there exist efficient solutions into an undecidable problem, if you remember your theory. Allowing expat to do this would be a very bad thing. Also, with regard to appending data to the buffer: I don't know what expat permits and does not permit in terms of modifying the buffer it is currently parsing, within a call stack descending from XML_Parse. Even if it does permit this, it seems very sketchy to me to provide access from your callbacks to the buffer currently being parsed. Regardless, you wouldn't have to make a recursive call to XML_Parse in either case. Note also that appending data to the buffer is not what the "isFinal" parameter is intended to do. You don't want to think of it as appending, you want to think of it as a signal to the parser when you're done refilling the buffer from whatever your original data source is (the file, for example). In summary: what you're trying to do is just not what you want to do. I don't know what exactly you're trying to do with the dynamic content you need to generate, but I'd guess that architecturally you'd rather approach this in two steps: first parse, then transform. Transformation during parsing can be difficult depending on the complexity of the transformation (see XSLT), and again, transformation of the source document being parsed is simply the wrong thing. Hope this helps, dr Derek Snider wrote: > It may not "make sense" to embed a call to XML_Parse, but it certainly > can be useful if you want to have XML elements which generate dynamic > XML content. > > I went the route of creating a second parser, but XML_Parse should be > robust enough to properly handle being called by an element handler. It > already supports appending data to the buffer (note the isFinal flag), > why not inserting data at the current point of parsing? > > > >>-----Original Message----- >>From: Greg Martin [mailto:Greg.Martin@telus.com] >>Sent: June 11, 2003 3:40 PM >>To: Derek Snider; expat-discuss@libexpat.org >>Subject: RE: [Expat-discuss] Nested calls to XML_Parse >> >> >>Expat is a stream oriented parser. It seems to me (as a >>bystander using the API) that it wouldn't make sense to embed >>a call to XML_Parse. You're not starting a new document you >>are simply parsing embedded tags and that's what your >>callback functions handle. A call to XML_Parse probably >>resets the state of the parser or the stream position(and >>hence your loop). I suppose if the contents of a tag was >>another xml document you could create a second parser object >>and call XML_Parse using that parser ... Regards, Greg. >> >>-----Original Message----- >>From: Derek Snider [mailto:derek@bluegenesis.com] >>Sent: Wednesday, June 11, 2003 11:42 AM >>To: expat-discuss@libexpat.org >>Subject: [Expat-discuss] Nested calls to XML_Parse >> >> >>Why do nested calls to XML_Parse (i.e. calling XML_Parse from >>within an element handler) end up putting the parser into an >>endless loop? >> >>I don't mean code-wise why the library acts this way, but why >>is this the intention? >> >>Is it not reasonable to want the possibility of XML elements >>expanding into more XML to be passed to the parser? >> >>It seems to add a lot of unneccessary overhead to require >>that nested parsing involve nested creation and freeing of >>additional parsers (the only way I could get this to work). >> >>Am I missing something? > > > > _______________________________________________ > Expat-discuss mailing list > Expat-discuss@libexpat.org > http://mail.libexpat.org/mailman/listinfo/expat-discuss From derek at bluegenesis.com Wed Jun 11 19:13:05 2003 From: derek at bluegenesis.com (Derek Snider) Date: Wed Jun 11 18:07:16 2003 Subject: [Expat-discuss] Nested calls to XML_Parse In-Reply-To: <3EE79E49.9020302@netscape.com> Message-ID: <0e8201c33066$a19db2d0$4d01a8c0@devnull.hostopia.com> I guess I should add a bit of case history here. Without going into too much detail, what we have is an Apache/PHP based (which uses libexpat) website management system that does interface layouts using XML template files. This system has evolved over the past year and a half as a scratch-rewrite from a "plain PHP" interface for the purpose of making things far more dynamic, easy to code and also support multiple languages. Not being XML wizards, the system we devised is relatively simple, but makes use of recursive calls to xml_parse to expand certain tags as well as embedded variables into XML data. (One example is that an embedded variable such as $GETDISKUSAGE will result in a call to a PHP function to lookup the disk usage for a customer, and expand to XML tags containing the data in the proper formatting.) Everything worked fine for the past year and a half until we tried to upgrade to php-4.3.2. I don't know why it worked (since libexpat does not support this), but it worked fine up to and including php-4.2.2. This system is used by over 100,000 customers, so it's not something we're about to scrap ;) However, it does appear that we're going to have to make some fundamental changes in the XML parsing. I originally reported this as a PHP bug, but further investigating revealed that the real issue was with our use of xml_parse. -Derek > -----Original Message----- > From: Dan Rosen [mailto:dr@netscape.com] > Sent: June 11, 2003 5:25 PM > To: Derek Snider > Cc: expat-discuss@libexpat.org > Subject: Re: [Expat-discuss] Nested calls to XML_Parse > > > Hi Derek, > > There is an important conceptual distinction here between > what you want to do and what a parser does. Any parser's role > is simply to parse serialized data into a programmatic > representation of that data, regardless of the type of data > or its representation. What you're trying to do transcends > parsing, and falls squarely into the domain of data > transformation and processing. > In the process of parsing, it is not appropriate (or is, at > least, very unorthodox) to modify the data stream being parsed. > Allowing this essentially turns a decidable problem for which > there exist efficient solutions into an undecidable problem, > if you remember your theory. > Allowing expat to do this would be a very bad thing. > Also, with regard to appending data to the buffer: I don't know > what expat permits and does not permit in terms of modifying the > buffer it is currently parsing, within a call stack descending > from XML_Parse. Even if it does permit this, it seems very sketchy > to me to provide access from your callbacks to the buffer currently > being parsed. Regardless, you wouldn't have to make a recursive > call to XML_Parse in either case. > Note also that appending data to the buffer is not what the > "isFinal" parameter is intended to do. You don't want to think of > it as appending, you want to think of it as a signal to the parser > when you're done refilling the buffer from whatever your original > data source is (the file, for example). > In summary: what you're trying to do is just not what you want to do. > I don't know what exactly you're trying to do with the dynamic content > you need to generate, but I'd guess that architecturally you'd rather > approach this in two steps: first parse, then transform. > Transformation during parsing can be difficult depending on the > complexity of the transformation (see XSLT), and again, transformation > of the source document being parsed is simply the wrong thing. > Hope this helps, > dr From dr at netscape.com Wed Jun 11 19:16:58 2003 From: dr at netscape.com (Dan Rosen) Date: Wed Jun 11 21:19:41 2003 Subject: [Expat-discuss] Nested calls to XML_Parse In-Reply-To: <0e8201c33066$a19db2d0$4d01a8c0@devnull.hostopia.com> References: <0e8201c33066$a19db2d0$4d01a8c0@devnull.hostopia.com> Message-ID: <3EE7D48A.7000605@netscape.com> Interesting application, and I understand now why you desire the ability to get the parsed data as if the dynamic insertion were transparent. It seems like the right thing to do in your case would be to make multiple parser instances, but register the same callback functions for each parser. That would give you the same transparency from the application code, since the order in which the parser callbacks are invoked should be correct. But definitely multiple parser instances are the way to go, in your case, hands down. You might be able to optimize the number of new parser instances you dynamically create and destroy. Some sort of list or stack ought to do... Best, dr Derek Snider wrote: > I guess I should add a bit of case history here. Without going into too > much detail, what we have is an Apache/PHP based (which uses libexpat) > website management system that does interface layouts using XML template > files. > > This system has evolved over the past year and a half as a > scratch-rewrite from a "plain PHP" interface for the purpose of making > things far more dynamic, easy to code and also support multiple > languages. > > Not being XML wizards, the system we devised is relatively simple, but > makes use of recursive calls to xml_parse to expand certain tags as well > as embedded variables into XML data. (One example is that an embedded > variable such as $GETDISKUSAGE will result in a call to a PHP function > to lookup the disk usage for a customer, and expand to XML tags > containing the data in the proper formatting.) > > Everything worked fine for the past year and a half until we tried to > upgrade to php-4.3.2. I don't know why it worked (since libexpat does > not support this), but it worked fine up to and including php-4.2.2. > > This system is used by over 100,000 customers, so it's not something > we're about to scrap ;) > > However, it does appear that we're going to have to make some > fundamental changes in the XML parsing. > > I originally reported this as a PHP bug, but further investigating > revealed that the real issue was with our use of xml_parse. > > -Derek From Florian.Douetteau at exalead.com Thu Jun 12 03:20:07 2003 From: Florian.Douetteau at exalead.com (Florian Douetteau) Date: Wed Jun 11 22:37:04 2003 Subject: [Expat-discuss] Nested calls to XML_Parse References: <0e8201c33066$a19db2d0$4d01a8c0@devnull.hostopia.com> Message-ID: <006801c33078$6114aea0$0201a8c0@foorama> There would be a very simple solution to your problem if Expat could guarantee that whenever XML_Parse is called, every EndElement and PCData callbacks that could have been called are actually called (the solution would be to feed XML_Parse with buffers stopping at each ">" and before each '$' of your xml input, and maintain your own stack of substituted text) My guess is that the actual implementation of Expat guarantees this property, and that every future version of Expat will, but i dread that it is a unspecified behaviour zone. ----- Original Message ----- From: "Derek Snider" To: Sent: Thursday, June 12, 2003 12:13 AM Subject: RE: [Expat-discuss] Nested calls to XML_Parse > I guess I should add a bit of case history here. Without going into too > much detail, what we have is an Apache/PHP based (which uses libexpat) > website management system that does interface layouts using XML template > files. > > This system has evolved over the past year and a half as a > scratch-rewrite from a "plain PHP" interface for the purpose of making > things far more dynamic, easy to code and also support multiple > languages. > > Not being XML wizards, the system we devised is relatively simple, but > makes use of recursive calls to xml_parse to expand certain tags as well > as embedded variables into XML data. (One example is that an embedded > variable such as $GETDISKUSAGE will result in a call to a PHP function > to lookup the disk usage for a customer, and expand to XML tags > containing the data in the proper formatting.) > > Everything worked fine for the past year and a half until we tried to > upgrade to php-4.3.2. I don't know why it worked (since libexpat does > not support this), but it worked fine up to and including php-4.2.2. > > This system is used by over 100,000 customers, so it's not something > we're about to scrap ;) > > However, it does appear that we're going to have to make some > fundamental changes in the XML parsing. > > I originally reported this as a PHP bug, but further investigating > revealed that the real issue was with our use of xml_parse. > > -Derek > > > > -----Original Message----- > > From: Dan Rosen [mailto:dr@netscape.com] > > Sent: June 11, 2003 5:25 PM > > To: Derek Snider > > Cc: expat-discuss@libexpat.org > > Subject: Re: [Expat-discuss] Nested calls to XML_Parse > > > > > > Hi Derek, > > > > There is an important conceptual distinction here between > > what you want to do and what a parser does. Any parser's role > > is simply to parse serialized data into a programmatic > > representation of that data, regardless of the type of data > > or its representation. What you're trying to do transcends > > parsing, and falls squarely into the domain of data > > transformation and processing. > > > In the process of parsing, it is not appropriate (or is, at > > least, very unorthodox) to modify the data stream being parsed. > > Allowing this essentially turns a decidable problem for which > > there exist efficient solutions into an undecidable problem, > > if you remember your theory. > > Allowing expat to do this would be a very bad thing. > > > Also, with regard to appending data to the buffer: I don't know > > what expat permits and does not permit in terms of modifying the > > buffer it is currently parsing, within a call stack descending > > from XML_Parse. Even if it does permit this, it seems very sketchy > > to me to provide access from your callbacks to the buffer currently > > being parsed. Regardless, you wouldn't have to make a recursive > > call to XML_Parse in either case. > > > Note also that appending data to the buffer is not what the > > "isFinal" parameter is intended to do. You don't want to think of > > it as appending, you want to think of it as a signal to the parser > > when you're done refilling the buffer from whatever your original > > data source is (the file, for example). > > > In summary: what you're trying to do is just not what you want to do. > > > I don't know what exactly you're trying to do with the dynamic content > > you need to generate, but I'd guess that architecturally you'd rather > > approach this in two steps: first parse, then transform. > > Transformation during parsing can be difficult depending on the > > complexity of the transformation (see XSLT), and again, transformation > > of the source document being parsed is simply the wrong thing. > > > Hope this helps, > > dr > > > _______________________________________________ > Expat-discuss mailing list > Expat-discuss@libexpat.org > http://mail.libexpat.org/mailman/listinfo/expat-discuss > From fabughazaleh at link.net.jo Fri Jun 13 02:36:56 2003 From: fabughazaleh at link.net.jo (Firas Abughazaleh) Date: Thu Jun 12 18:52:30 2003 Subject: [Expat-discuss] Expat Performance Message-ID: <003701c33133$21de3650$c1a15a50@firas> Hi guys, I have a problem of expat parsing being too much slow on a PDA device running Windows CE. Can anyone pinpoint some healthy rules for high performance parsing for large xml documents using EXPAT xml parser ? Or any ideas, hints, tips ? Thanks alot, - Firas From karl at waclawek.net Thu Jun 12 21:54:33 2003 From: karl at waclawek.net (Karl Waclawek) Date: Thu Jun 12 20:53:38 2003 Subject: [Expat-discuss] Expat Performance References: <003701c33133$21de3650$c1a15a50@firas> Message-ID: <000701c33146$5ac3a9b0$0207a8c0@karl> > I have a problem of expat parsing being too much slow on a PDA device running Windows CE. > Can anyone pinpoint some healthy rules for high performance parsing for large xml documents > using EXPAT xml parser ? Or any ideas, hints, tips ? Compared to what other parser? Does MSXML work on CE? If yes, how does it compare to Expat? As far as tips are concerned: There is not much one can do. Maybe play with compiler options for Expat. Use larger buffers when calling XML_Parse(Buffer). Make sure that it isn't your handlers that consume most of the CPU cycles. Karl From mecarmonasw at mailbanamex.com Fri Jun 13 15:59:38 2003 From: mecarmonasw at mailbanamex.com (mecarmonasw@mailbanamex.com) Date: Fri Jun 13 17:59:44 2003 Subject: [Expat-discuss] (no subject) Message-ID: <20030613145938.2201.h010.c003.wm@mail.mailbanamex.com.criticalpath.net> Hi, I am starting to use expat XML parser.....i already install and give the following commands: ./configure make make install Now...i am trying to prove a example...but it give me the following error....somebody could help me please? any ideas or suggestion are welcome..... Thanks in advance, Mary $ cc examples/outline.c -o o #include ^ "/dir/direct/expat/expat-1.95.6/examples/outlin e.c", line 25: error(1003): could not open source file "expat.h" 1 catastrophic error detected in the compilation of "examples/outline.c". Compilation terminated. From carlos at pehoe.civil.ist.utl.pt Sat Jun 14 17:57:37 2003 From: carlos at pehoe.civil.ist.utl.pt (Carlos Pereira) Date: Sat Jun 14 11:50:47 2003 Subject: [Expat-discuss] Re: no subject Message-ID: <20030614155737.6D99654C@pehoe.civil.ist.utl.pt> >$ cc examples/outline.c -o o > #include > ^ >"/dir/direct/expat/expat-1.95.6/examples/outlin >e.c", line 25: error(1003): > could not open source file "expat.h" Are you on Unix/Linux? If you are using non-standard locations for your libraries, you must tell the compiler AND the linker where are the files, for example using directives as this: cc examples/outline.c -o o -I/my_path_to_expat/expat/include -L/my_path_to_expat/expat/lib perhaps you also need to add the library path to /etc/ld.so.conf, and run /sbin/ldconfig you should read something about how to use libraries in Unix/Linux Carlos From joe at manyfish.co.uk Tue Jun 17 22:56:12 2003 From: joe at manyfish.co.uk (Joe Orton) Date: Tue Jun 17 17:00:25 2003 Subject: [Expat-discuss] [PATCH] libtool.m4 detection Message-ID: <20030617205612.GA29879@manyfish.co.uk> This patch adds support for finding libtool.m4 in places other than the expected default using the $LIBTOOL_M4 variable. (imagine a libtool configured with --prefix=/opt --datadir=/foo, for instance) --- buildconf.sh.~1.9.~ 2003-06-17 21:51:49.000000000 +0100 +++ buildconf.sh 2003-06-17 21:52:33.000000000 +0100 @@ -67,9 +67,11 @@ $libtoolize --copy --automake ltpath=`dirname $libtoolize` -ltfile=`cd $ltpath/../share/aclocal ; pwd`/libtool.m4 +ltfile=${LIBTOOL_M4-`cd $ltpath/../share/aclocal ; pwd`/libtool.m4} cp $ltfile conftools/libtool.m4 +echo "Use libtool.m4 from ${ltfile}." + #-------------------------------------------------------------------------- ### for a little while... remove stray aclocal.m4 files from From gstein at lyra.org Tue Jun 17 19:16:59 2003 From: gstein at lyra.org (Greg Stein) Date: Tue Jun 17 21:12:19 2003 Subject: [Expat-discuss] [PATCH] libtool.m4 detection In-Reply-To: <20030617205612.GA29879@manyfish.co.uk> References: <20030617205612.GA29879@manyfish.co.uk> Message-ID: <20030618011659.GD9719@lyra.org> Applied in revision 1.10 of buildconf.sh with some minor changes. Thanks, Joe! Cheers, -g On Tue, Jun 17, 2003 at 09:56:12PM +0100, Joe Orton wrote: > This patch adds support for finding libtool.m4 in places other than the > expected default using the $LIBTOOL_M4 variable. (imagine a libtool > configured with --prefix=/opt --datadir=/foo, for instance) > > --- buildconf.sh.~1.9.~ 2003-06-17 21:51:49.000000000 +0100 > +++ buildconf.sh 2003-06-17 21:52:33.000000000 +0100 > @@ -67,9 +67,11 @@ > $libtoolize --copy --automake > > ltpath=`dirname $libtoolize` > -ltfile=`cd $ltpath/../share/aclocal ; pwd`/libtool.m4 > +ltfile=${LIBTOOL_M4-`cd $ltpath/../share/aclocal ; pwd`/libtool.m4} > cp $ltfile conftools/libtool.m4 > > +echo "Use libtool.m4 from ${ltfile}." > + > #-------------------------------------------------------------------------- > > ### for a little while... remove stray aclocal.m4 files from -- Greg Stein, http://www.lyra.org/ From rishikesh_mallesh at yahoo.com Wed Jun 18 03:26:50 2003 From: rishikesh_mallesh at yahoo.com (rishikesh mallesh) Date: Wed Jun 18 05:26:55 2003 Subject: [Expat-discuss] Problems building expat. on HP-UX 11i Message-ID: <20030618092650.99031.qmail@web12807.mail.yahoo.com> Hello I have a quick question, I am trying to build the expat code on HPUX 11i. The build went through without an issue when building with "gcc". But I wanted to build the code with "cc" , but the problem is that I have no clue on where to specify this. Mind you that I am new to the whole "autoconf" and "automake", which may just explain the "duh" question I have. I would really appreciate your help on this. Many thanks, Rishi ===== Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From GSubhash at chn.cognizant.com Thu Jun 19 15:53:54 2003 From: GSubhash at chn.cognizant.com (Gururajan, Subhashini (Cognizant)) Date: Thu Jun 19 05:21:20 2003 Subject: [Expat-discuss] Problems building expat. on HP-UX 11i Message-ID: <14E2ECED6A08844980C5C5C9BDD247B10143B327@ctsinentsxua.cts.com> Hi, How do I stop the parsing in the middle and come out, if I see any missing tags (validated in my program) Please help me. -Subhashini -----Original Message----- From: rishikesh mallesh [mailto:rishikesh_mallesh@yahoo.com] Sent: Wednesday, June 18, 2003 2:57 PM To: expat-discuss@libexpat.org Subject: [Expat-discuss] Problems building expat. on HP-UX 11i Hello I have a quick question, I am trying to build the expat code on HPUX 11i. The build went through without an issue when building with "gcc". But I wanted to build the code with "cc" , but the problem is that I have no clue on where to specify this. Mind you that I am new to the whole "autoconf" and "automake", which may just explain the "duh" question I have. I would really appreciate your help on this. Many thanks, Rishi ===== Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com _______________________________________________ Expat-discuss mailing list Expat-discuss@libexpat.org http://mail.libexpat.org/mailman/listinfo/expat-discuss -------------- next part -------------- This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. Visit us at http://www.cognizant.com From w_k_henning at hotmail.com Fri Jun 20 08:24:09 2003 From: w_k_henning at hotmail.com (warren henning) Date: Fri Jun 20 03:24:44 2003 Subject: [Expat-discuss] Example of using Expat with Unicode? Message-ID: Hi, This email is pretty long, so if you don't feel like reading here's what I'm really basically asking: I am humbly requesting is a way to read in XML in Expat such that I can handle Unicode stuff, using XML_Char's throughout the program rather than char's. I downloaded Expat from Jclark.com and have been trying to figure out how to use it. I looked at the sample program, "elements.c" and basically figured out what to do based on that. However, that program prints out the character data for some XML files (the one that made me notice this is located at http://www.aaronsw.com/weblog/index.xml - what appears as "10% think it’s advantageous to be a woman in American society" in Internet Explorer's XML viewer appears as "10% think it’s advantageous to be a woman in American society".) The file was being read from disk using standard C file i/o functions - all I did was open up a FILE* structure with a call to fopen() and replaced "fread(buf, 1, sizeof(buf), stdin)" with "fread(buf, 1, sizeof(buf), my_file_structure". This worked fine except for this Unicode stuff that my normal functions seemed to read in incorrectly. (I am using Windows and Visual C++ 6.0, by the way.) Now I figured I should modify my file I/O and string functions to use the Unicode equivalents of the ones I was using before -- e.g., _wfopen instead of fopen. My element handles would take XML_Char's as parameters instead of char's. I had quite a bit of other stuff in the code that I thought could go wrong so I figured I'd make a little separate test program to make sure I understood how to do Unicode file I/O. This was the test program: #include #include #include int main(int argc, char** argv) { wchar_t test[5]; size_t len; FILE* fp; if((fp = _wfopen(L"xml_test.xml",L"r")) == NULL) { wprintf(L"_wfopen failed.\n"); return(0); } len = fread(test, sizeof(wchar_t), 5, fp); wprintf(L"%d\n",len); /*if(fgetws(test, BUFSIZ, fp) == NULL) { printf("fgetws\n"); fclose(fp); return 0; }*/ wprintf(L"%s\n",test); fclose(fp); return 0; } xml_test.xml is the file containing just the part that IE showed as "it's". That file can be viewed at http://wkh.daysbackwhen.com/xml_test.xml You see that I have an fread() similar to what I thought I would be using in my modified, Unicode-using program -- I thought I would be reading in blocks of wchar_t's instead of char's. Well that produced no output when run except the printing out of the len variable which worked as expected -- so I tried using fgetws as an alternative method (after commenting out the fread and print len lines) -- that part is currently commented out in the lines above. Doing so crashed after it printed out: 2 itΓÇÖs The 2 part was expected. Crashing after apparently trying to print Unicode as ASCII was not. So I'm basically out of ideas. I tried downloading the latest version for Windows -- 1.95.6 -- thinking maybe I should just forget about Unicode file I/O and just try modifying the elements.c program and seeing what would happen but couldn't get the samples for the new version to build in Visual C++ -- I get the following error: LINK : fatal error LNK1181: cannot open input file "libexpatMT.lib" So what I am humbly requesting is a way to read in XML in Expat such that I can handle Unicode stuff like the aaronsw.com feed. Just basically a modified version of the sample program. If possible I would like to also see how this would be done for parsing an XML file on disk. I have done my best to figure this out. Any help is much appreciated! Sincerely, Warren _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From karl at waclawek.net Fri Jun 20 10:13:17 2003 From: karl at waclawek.net (Karl Waclawek) Date: Fri Jun 20 09:13:25 2003 Subject: [Expat-discuss] Example of using Expat with Unicode? References: Message-ID: <001001c3372d$b712e270$9e539696@citkwaclaww2k> > Hi, > > This email is pretty long, so if you don't feel like reading here's what I'm > really basically asking: I am humbly requesting is a way to read in XML in > Expat such that I can handle Unicode stuff, using XML_Char's throughout the > program rather than char's. Expat reports all XML data as UTF-8 or UTF-16 encoded Unicode, depending on how it is compiled. Expat reads XML documents encoded in US-ASCII, ISO-8859-1, UTF-8 or UTF-16, and more if you supply an UnknownEncodingHandler callback. I didn't quite understand your problems, to be honest. Expat, like any conformant parser, processes and outputs Unicode. > I downloaded Expat from Jclark.com and have been trying to figure out how to > use it. I looked at the sample program, "elements.c" and basically figured > out what to do based on that. However, that program prints out the character > data for some XML files (the one that made me notice this is located at > http://www.aaronsw.com/weblog/index.xml - what appears as "10% think it?s > advantageous to be a woman in American society" in Internet Explorer's XML > viewer appears as "10% think it???s advantageous to be a woman in American > society".) The file was being read from disk using standard C file i/o > functions - all I did was open up a FILE* structure with a call to fopen() > and replaced "fread(buf, 1, sizeof(buf), stdin)" with "fread(buf, 1, > sizeof(buf), my_file_structure". This worked fine except for this Unicode > stuff that my normal functions seemed to read in incorrectly. Since Expat output is Unicode, you need ways of displaying it correctly. Standard string display does not do that. > > (I am using Windows and Visual C++ 6.0, by the way.) On Windoes you should compile Expat with XML_UNICODE_WCHAR_T defined, or simply build the "expatw" library project. The Unicode encoding native to Windows is UTF-16. > > Now I figured I should modify my file I/O and string functions to use the > Unicode equivalents of the ones I was using before -- e.g., _wfopen instead > of fopen. My element handles would take XML_Char's as parameters instead of > char's. I had quite a bit of other stuff in the code that I thought could go > wrong so I figured I'd make a little separate test program to make sure I > understood how to do Unicode file I/O. This was the test program: When you pass data to Expat you should consider them generic buffers of bytes, no matter what the encoding is. > So I'm basically out of ideas. I tried downloading the latest version for > Windows -- 1.95.6 -- thinking maybe I should just forget about Unicode file > I/O and just try modifying the elements.c program and seeing what would > happen but couldn't get the samples for the new version to build in Visual > C++ -- I get the following error: > > LINK : fatal error LNK1181: cannot open input file "libexpatMT.lib" Builds fine for me in the VC++ 6.0 IDE. The older versions (from jclark.com) does not work for UTF-16 output, AFAIK. 1.95.6 is the most stable and conformant version yet. > > So what I am humbly requesting is a way to read in XML in Expat such that I > can handle Unicode stuff like the aaronsw.com feed. Not needed, it already does it. Just pass it byte-buffers. > Just basically a > modified version of the sample program. If possible I would like to also see > how this would be done for parsing an XML file on disk. Have a look at the xmlwf tool. Karl From nchan at cisco.com Mon Jun 23 14:22:41 2003 From: nchan at cisco.com (Chandran N) Date: Mon Jun 23 03:53:23 2003 Subject: [Expat-discuss] eXpat : reduced in size version ? Message-ID: <009001c3395c$6daa7d10$8f8a4d0a@apac.cisco.com> Hi All, Do eXpat have plans to come up with a xml parser, reduced in size with minimal functionality (parse only well-formed documents) ? It would be great, If the size is not more than 30K (very useful for embedded systems). Thanks a lot. Chandran. From karl at waclawek.net Mon Jun 23 10:57:22 2003 From: karl at waclawek.net (Karl Waclawek) Date: Mon Jun 23 09:57:27 2003 Subject: [Expat-discuss] eXpat : reduced in size version ? References: <009001c3395c$6daa7d10$8f8a4d0a@apac.cisco.com> Message-ID: <003201c3398f$5ecf3410$9e539696@citkwaclaww2k> > Hi All, > > Do eXpat have plans to come up with a xml parser, reduced in size with > minimal functionality (parse only well-formed documents) ? > > It would be great, If the size is not more than 30K (very useful for > embedded systems). Try compiling Expat with XML_DTD undefined and XML_MIN_SIZE defined. Not sure how well tested this combination is. On Windows this reduces size by abut 20%, but the Dll is still much larger than what you want. Btw, Expat does only WF-parsing, no validation. Karl From nchan at cisco.com Tue Jun 24 00:48:46 2003 From: nchan at cisco.com (Chandran N) Date: Mon Jun 23 14:19:25 2003 Subject: [Expat-discuss] eXpat : reduced in size version ? In-Reply-To: <003201c3398f$5ecf3410$9e539696@citkwaclaww2k> Message-ID: <00ab01c339b3$e4284740$8f8a4d0a@apac.cisco.com> Hi Karl, Thanks a lot for your quick reply. -----Original Message----- From: Karl Waclawek [mailto:karl@waclawek.net] Sent: Monday, June 23, 2003 7:27 PM To: nchan@cisco.com; expat-discuss@libexpat.org Subject: Re: [Expat-discuss] eXpat : reduced in size version ? > Hi All, > > Do eXpat have plans to come up with a xml parser, reduced in size with > minimal functionality (parse only well-formed documents) ? > > It would be great, If the size is not more than 30K (very useful for > embedded systems). Try compiling Expat with XML_DTD undefined and XML_MIN_SIZE defined. Not sure how well tested this combination is. --> Tried both ! They resulted in reducing the parser size, but not to my need ! On Windows this reduces size by abut 20%, but the Dll is still much larger than what you want. Btw, Expat does only WF-parsing, no validation. --> Hope eXpat also does DTD validation. -Chandran. Karl From karl at waclawek.net Mon Jun 23 15:28:29 2003 From: karl at waclawek.net (Karl Waclawek) Date: Mon Jun 23 14:28:37 2003 Subject: [Expat-discuss] eXpat : reduced in size version ? References: <00ab01c339b3$e4284740$8f8a4d0a@apac.cisco.com> Message-ID: <003701c339b5$3e42e0e0$9e539696@citkwaclaww2k> > Try compiling Expat with XML_DTD undefined and XML_MIN_SIZE defined. > Not sure how well tested this combination is. > --> Tried both ! They resulted in reducing the parser size, but not to my > need ! Yes, I expected that. > On Windows this reduces size by abut 20%, but the Dll is still much larger > than what you want. Btw, Expat does only WF-parsing, no validation. > --> Hope eXpat also does DTD validation. No, Expat does not do DTD validation, unfortunately. This is not needed in many cases, as applications often perform their own checks anyway. One can build DTD validation on top of Expat, with the exception of these "Validity Constraints": - "Proper Declaration/PE Nesting" - "Standalone Document Declaration" - "Proper Group/PE Nesting" - "Proper Conditional Section/PE Nesting" Karl From gstein at lyra.org Tue Jun 24 02:10:02 2003 From: gstein at lyra.org (Greg Stein) Date: Tue Jun 24 04:05:01 2003 Subject: [Expat-discuss] Re: [Expat-checkins] Bug C XML paser In-Reply-To: <215AAB9D253A164CA780A20F39DB609102310F0B@MAIL1.hcwml.com> References: <215AAB9D253A164CA780A20F39DB609102310F0B@MAIL1.hcwml.com> Message-ID: <20030624081002.GB29972@lyra.org> On Mon, Jun 23, 2003 at 08:33:43PM +0700, Suebsakul Ampa wrote: > I install Expat in Server but I can't Run Check and Run Program use > include xml for XML Paser > > I type Command Unix Result > I make Doumentation but I can't ......... > > > > $ make check > gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes > -fexceptions -I./lib -I. -o tests/runtests.o -c tests/runtests.c > tests/runtests.c:2: check.h: No such file or directory You can run 'make check' without the check package installed. I know nothing about the package, but Fred may be able to comment. (there is an open bug about providing a nice warning/feedback when you try to do this 'make check' without the proper dependencies...) Cheers, -g -- Greg Stein, http://www.lyra.org/ From michal017 at centrum.sk Tue Jun 24 15:38:21 2003 From: michal017 at centrum.sk (m.) Date: Tue Jun 24 08:38:42 2003 Subject: [Expat-discuss] c++-ize expat Message-ID: <20030624143821.1d2cacfe.michal017@centrum.sk> Hello.. I am wondering whether it is possible to c++-ize expat's code so that it could be compiled with c++ compiler. The reason for this is the ability to throw exceptions from callback functions. I have to remove all the 'extern "C"' stuff from expat code and cast all the void* to FILE* and so on.. Could this be done in the default expat's code? Thanks.. michal From fdrake at acm.org Tue Jun 24 09:47:06 2003 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Tue Jun 24 08:47:38 2003 Subject: [Expat-discuss] c++-ize expat In-Reply-To: <20030624143821.1d2cacfe.michal017@centrum.sk> References: <20030624143821.1d2cacfe.michal017@centrum.sk> Message-ID: <16120.18506.41728.88725@grendel.zope.com> m. writes: > I am wondering whether it is possible to c++-ize expat's code so > that it could be compiled with c++ compiler. The reason for this > is the ability to throw exceptions from callback functions. I have > to remove all the 'extern "C"' stuff from expat code and cast all > the void* to FILE* and so on.. Could this be done in the default > expat's code? Thanks.. michal It's not at all clear what you need. Expat is a C library, but most of the C++ compilers out there should be fairly happy with it. We normally build it with support for C++ exceptions, so I don't understand what you're having problems with. Please be more specific; it'll be easier to help. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From michal017 at centrum.sk Tue Jun 24 16:37:10 2003 From: michal017 at centrum.sk (m.) Date: Tue Jun 24 09:37:31 2003 Subject: [Expat-discuss] c++-ize expat In-Reply-To: <16120.18506.41728.88725@grendel.zope.com> References: <20030624143821.1d2cacfe.michal017@centrum.sk> <16120.18506.41728.88725@grendel.zope.com> Message-ID: <20030624153710.00b48395.michal017@centrum.sk> The problem is expat can't be compiled with c++ compiler (g++ in my case). There are many implicit casts from void* to FILE* for instance that have to be done explicitely. m. On Tue, 24 Jun 2003 08:47:06 -0400 "Fred L. Drake, Jr." wrote: > >m. writes: > > I am wondering whether it is possible to c++-ize expat's code so > > that it could be compiled with c++ compiler. The reason for this > > is the ability to throw exceptions from callback functions. I have > > to remove all the 'extern "C"' stuff from expat code and cast all > > the void* to FILE* and so on.. Could this be done in the default > > expat's code? Thanks.. michal > >It's not at all clear what you need. Expat is a C library, but most >of the C++ compilers out there should be fairly happy with it. We >normally build it with support for C++ exceptions, so I don't >understand what you're having problems with. > >Please be more specific; it'll be easier to help. > > > -Fred > >-- >Fred L. Drake, Jr. >PythonLabs at Zope Corporation > > From fdrake at acm.org Tue Jun 24 11:08:33 2003 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Tue Jun 24 10:09:14 2003 Subject: [Expat-discuss] c++-ize expat In-Reply-To: <20030624153710.00b48395.michal017@centrum.sk> References: <20030624143821.1d2cacfe.michal017@centrum.sk> <16120.18506.41728.88725@grendel.zope.com> <20030624153710.00b48395.michal017@centrum.sk> Message-ID: <16120.23393.780325.308790@grendel.zope.com> m. writes: > The problem is expat can't be compiled with c++ compiler (g++ in my case). > There are many implicit casts from void* to FILE* for instance that have to be done explicitely. Hmm. Please open a formal bug report on SourceForge, and include the g++ output from attempting to compile the main library. Bug reports may be filed at: http://sourceforge.net/tracker/?atid=110127&group_id=10127&func=browse -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From villas at del.ufrj.br Tue Jun 24 12:18:40 2003 From: villas at del.ufrj.br (Sergio Barbosa Villas-Boas) Date: Tue Jun 24 10:18:49 2003 Subject: [Expat-discuss] expat in C++ Message-ID: > > Could this be done in the default > > expat's code? Thanks.. michal > > It's not at all clear what you need. Expat is a C library, but most > of the C++ compilers out there should be fairly happy with it. We > normally build it with support for C++ exceptions, so I don't > understand what you're having problems with. > > Please be more specific; it'll be easier to help. I agree with michal. Expat is written in "tricky C", that is, a kind of C code that a more strict C++ compiler won't accept. My VC6SP5 can't compile expat directly. I use the binary version of it, but that's not the way it should be. I'm still looking for an expat based C++ code, that compiles easily in every important C++ compiler. Should someone have it, I'd be glad to see a copy. --------------------------------------------------------- +------+ Sergio Barbosa Villas-Boas /------/| villas@del.ufrj.br | sbVB |/ http://www.del.ufrj.br/~villas http://www.sbVB.net +------+ ICQ: 15360729 From fdrake at acm.org Tue Jun 24 11:30:02 2003 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Tue Jun 24 10:30:37 2003 Subject: [Expat-discuss] expat in C++ In-Reply-To: References: Message-ID: <16120.24682.264159.650021@grendel.zope.com> Sergio Barbosa Villas-Boas writes: > Expat is written in "tricky C", that is, > a kind of C code that a more strict C++ compiler > won't accept. It certainly can be tricky! > My VC6SP5 can't compile expat directly. > I use the binary version of it, but that's not the way > it should be. Hmm. On Windows, I'm using VC6, but am not sure of the specific service pack. I'll see if I can figure out what I have when I get back to that machine (Windows is not my normal environment). Karl, which flavor are you using these days? Is there some magic flag I need to set to see the problems being reported? -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From karl at waclawek.net Tue Jun 24 11:47:00 2003 From: karl at waclawek.net (Karl Waclawek) Date: Tue Jun 24 10:47:10 2003 Subject: [Expat-discuss] expat in C++ References: <16120.24682.264159.650021@grendel.zope.com> Message-ID: <005001c33a5f$78042eb0$9e539696@citkwaclaww2k> > Sergio Barbosa Villas-Boas writes: > > Expat is written in "tricky C", that is, > > a kind of C code that a more strict C++ compiler > > won't accept. > > It certainly can be tricky! > > > My VC6SP5 can't compile expat directly. > > I use the binary version of it, but that's not the way > > it should be. > > Hmm. On Windows, I'm using VC6, but am not sure of the specific > service pack. I'll see if I can figure out what I have when I get > back to that machine (Windows is not my normal environment). > > Karl, which flavor are you using these days? Is there some magic flag > I need to set to see the problems being reported? I have VC++ 6.0 SP5 and I have no problems compiling Expat. Just load the workspace and build the various projects. I can't recall having changed anything from the defaults. Maybe Sergio's VC++ 6 installation is corrupted? Karl From xcross at us.ibm.com Tue Jun 24 13:28:31 2003 From: xcross at us.ibm.com (Chris Cross) Date: Tue Jun 24 12:33:25 2003 Subject: [Expat-discuss] DTD validation Message-ID: Hi Karl, What's the basic approach you would use to build DTD validation on top of Expat? I've built a VoiceXML interpreter using expat and just use the most basic features, start/end element and character data handlers. Would you parse the DTD and create some sort of schema or object model? Is there some way to cause expat to use it or do you just call the validation in the element handler? >> --> Hope eXpat also does DTD validation. > >No, Expat does not do DTD validation, unfortunately. > >This is not needed in many cases, as applications often perform their own checks anyway. >One can build DTD validation on top of Expat, with the exception of these >"Validity Constraints": > >- "Proper Declaration/PE Nesting" >- "Standalone Document Declaration" >- "Proper Group/PE Nesting" >- "Proper Conditional Section/PE Nesting" > > >Karl thanks, chris Chris Cross IBM Boca Raton xcross@us.ibm.com voice 561.862.2102 t/l 975.2102 fax 561.862.3922 From karl at waclawek.net Tue Jun 24 14:17:55 2003 From: karl at waclawek.net (Karl Waclawek) Date: Tue Jun 24 13:18:04 2003 Subject: [Expat-discuss] DTD validation References: Message-ID: <007601c33a74$8d0e5550$9e539696@citkwaclaww2k> > Hi Karl, > What's the basic approach you would use to build DTD validation on top of > Expat? I've built a VoiceXML interpreter using expat and just use the most > basic features, start/end element and character data handlers. Would you > parse the DTD and create some sort of schema or object model? Is there some > way to cause expat to use it or do you just call the validation in the > element handler? There are likely many ways. I am just about to finish a DTD validator in Delphi (based on SAX2 events), with Expat as the underlying parser. In my case I opted to create a schema object model (basically, one node per element type, and a tree of "content particle" nodes for each element type with element content). My main reason (except validation) was to have a way to attach event handlers on a more granular basis - that is, it allows me to register an event handler for an element type. This allows me to organize my code in a more convenient fashion. There might be more to find on our links page. I also know that Rolf Ade wrote a DTD validator for Tcl, based on Expat. You might want to have a look at that one too. http://www.tdom.org . Karl From w_k_henning at hotmail.com Tue Jun 24 19:08:54 2003 From: w_k_henning at hotmail.com (warren henning) Date: Tue Jun 24 14:09:27 2003 Subject: [Expat-discuss] expat in C++ Message-ID: I'm also using VC6SP5 and can also build just fine. -Warren >I have VC++ 6.0 SP5 and I have no problems compiling Expat. >Just load the workspace and build the various projects. _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From xcross at us.ibm.com Tue Jun 24 15:52:07 2003 From: xcross at us.ibm.com (Chris Cross) Date: Tue Jun 24 14:51:24 2003 Subject: [Expat-discuss] DTD validation Message-ID: So how does one parse a DTD? I see to call XML_SetParamEntityParsing. Are there API's to help expand the entities or do you have to just roll your own with start/end element handler? Is there a simple example of parsing DTD's (like outline.c ?) thanks, chris Chris Cross IBM Boca Raton xcross@us.ibm.com voice 561.862.2102 t/l 975.2102 fax 561.862.3922 "Karl Waclawek" , Chris Cross/West Palm Beach/IBM@IBMUS t> cc: Subject: Re: [Expat-discuss] DTD validation 06/24/2003 01:17 PM > Hi Karl, > What's the basic approach you would use to build DTD validation on top of > Expat? I've built a VoiceXML interpreter using expat and just use the most > basic features, start/end element and character data handlers. Would you > parse the DTD and create some sort of schema or object model? Is there some > way to cause expat to use it or do you just call the validation in the > element handler? There are likely many ways. I am just about to finish a DTD validator in Delphi (based on SAX2 events), with Expat as the underlying parser. In my case I opted to create a schema object model (basically, one node per element type, and a tree of "content particle" nodes for each element type with element content). My main reason (except validation) was to have a way to attach event handlers on a more granular basis - that is, it allows me to register an event handler for an element type. This allows me to organize my code in a more convenient fashion. There might be more to find on our links page. I also know that Rolf Ade wrote a DTD validator for Tcl, based on Expat. You might want to have a look at that one too. http://www.tdom.org . Karl From fdrake at acm.org Tue Jun 24 15:54:58 2003 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Tue Jun 24 14:55:28 2003 Subject: [Expat-discuss] DTD validation In-Reply-To: References: Message-ID: <16120.40578.456867.668012@grendel.zope.com> Chris Cross writes: > So how does one parse a DTD? I see to call XML_SetParamEntityParsing. Are > there API's to help expand the entities or do you have to just roll your > own with start/end element handler? Is there a simple example of parsing > DTD's (like outline.c ?) Once you parse the parameter entities, you can register additional callbacks to pick up information on the structural declarations (see doc/reference.html in the distribution) and then check the structure in the element start/end handlers. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From karl at waclawek.net Tue Jun 24 15:59:53 2003 From: karl at waclawek.net (Karl Waclawek) Date: Tue Jun 24 14:59:58 2003 Subject: [Expat-discuss] DTD validation References: Message-ID: <00d001c33a82$cbb3bee0$9e539696@citkwaclaww2k> > So how does one parse a DTD? I see to call XML_SetParamEntityParsing. Are > there API's to help expand the entities or do you have to just roll your > own with start/end element handler? Is there a simple example of parsing > DTD's (like outline.c ?) There is a range of callbacks you can register with Expat. They cover practically everything in the DTD. Expat silently expands internal entities, and you need to set a handler to parse external entities. Details in reference.html. You should also check the example applications, like xmlwf. Karl From david.parker at rocketsoftware.com Tue Jun 24 16:16:47 2003 From: david.parker at rocketsoftware.com (David Parker) Date: Tue Jun 24 15:21:56 2003 Subject: [Expat-discuss] port to OS/390 Message-ID: <9BFCEB1E1A274A49A866B6E9290752D6DC1640@hqsmtp.rocketsoftware.com> I would be interested to hear if anybody has attempted porting expat to OS/390 UNIX. I gave configure a quick try, and it doesn't work out of the box. I have been struggling getting other open source packages to build, so I might go ahead and work on getting expat ported, but I thought I would check around. It's still an open issue whether the app I'm building needs a parser or not (but you can ALWAYS find something to use XML for....;-) ), so I might not get to this any time soon... Any hints/clues/dire-warnings would be appreciated! - DAP -------------------------------------------------------------------------- David Parker Rocket Software (617) 614-2128 From graham-expat at simulcra.org Wed Jun 25 00:29:01 2003 From: graham-expat at simulcra.org (Graham Bennett) Date: Tue Jun 24 18:29:00 2003 Subject: [Expat-discuss] c++-ize expat In-Reply-To: <20030624222623.GA5561@lamity.org> References: <20030624143821.1d2cacfe.michal017@centrum.sk> <20030624222623.GA5561@lamity.org> Message-ID: <20030624222901.GB5561@lamity.org> On Tue, Jun 24, 2003 at 02:38:21PM +0200, m. wrote: > Hello.. I am wondering whether it is possible to c++-ize expat's code > so that it could be compiled with c++ compiler. The reason for this > is the ability to throw exceptions from callback functions. I have to > remove all the 'extern "C"' stuff from expat code and cast all the > void* to FILE* and so on.. Could this be done in the default expat's > code? In order to use expat from C++ code it is not necessary to compile with g++. All that you need is to compile with gcc with the -fexceptions flag. This generates the necessary stack unwinding code to allow exceptions to be thrown. IIRC, the expat configure script will enable the -fexceptions flag if it detects the compiler is gcc (even though it checks for -fno-exceptions). Try it and see. I have used expat from C++ code compiled in this way and I've had no problems throwing exceptions through expat code. cheers, -- Graham Bennett From GSubhash at chn.cognizant.com Wed Jun 25 11:36:24 2003 From: GSubhash at chn.cognizant.com (Gururajan, Subhashini (Cognizant)) Date: Wed Jun 25 01:07:03 2003 Subject: [Expat-discuss] expat in C++ Message-ID: <14E2ECED6A08844980C5C5C9BDD247B10158632E@ctsinentsxua.cts.com> Hi, I downloaded the C++ wrapper written for expat. And compiled using SUn C++ compiler. There was no problem. I downloaded the wrapper from http://www.codeproject.com/soap/expatimpl.asp Hope this helps. -Subha -----Original Message----- From: warren henning [mailto:w_k_henning@hotmail.com] Sent: Tuesday, June 24, 2003 11:39 PM To: expat-discuss@libexpat.org Subject: Re: [Expat-discuss] expat in C++ I'm also using VC6SP5 and can also build just fine. -Warren >I have VC++ 6.0 SP5 and I have no problems compiling Expat. >Just load the workspace and build the various projects. _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ Expat-discuss mailing list Expat-discuss@libexpat.org http://mail.libexpat.org/mailman/listinfo/expat-discuss -------------- next part -------------- This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. Visit us at http://www.cognizant.com From michal017 at centrum.sk Wed Jun 25 08:54:55 2003 From: michal017 at centrum.sk (m.) Date: Wed Jun 25 01:55:14 2003 Subject: [Expat-discuss] c++-ize expat In-Reply-To: <20030624222901.GB5561@lamity.org> References: <20030624143821.1d2cacfe.michal017@centrum.sk> <20030624222623.GA5561@lamity.org> <20030624222901.GB5561@lamity.org> Message-ID: <20030625075455.26768a61.michal017@centrum.sk> You know what? You are entirely right.. This information was based on my colleague's knowledge, I should have tested it before I posted a question.. My apologies michal On Tue, 24 Jun 2003 23:29:01 +0100 Graham Bennett wrote: >On Tue, Jun 24, 2003 at 02:38:21PM +0200, m. wrote: >> Hello.. I am wondering whether it is possible to c++-ize expat's code >> so that it could be compiled with c++ compiler. The reason for this >> is the ability to throw exceptions from callback functions. I have to >> remove all the 'extern "C"' stuff from expat code and cast all the >> void* to FILE* and so on.. Could this be done in the default expat's >> code? > >In order to use expat from C++ code it is not necessary to compile with >g++. All that you need is to compile with gcc with the -fexceptions >flag. This generates the necessary stack unwinding code to allow >exceptions to be thrown. > >IIRC, the expat configure script will enable the -fexceptions flag if it >detects the compiler is gcc (even though it checks for -fno-exceptions). >Try it and see. > >I have used expat from C++ code compiled in this way and I've had no >problems throwing exceptions through expat code. > >cheers, > >-- >Graham Bennett > > From GSubhash at chn.cognizant.com Mon Jun 30 19:26:45 2003 From: GSubhash at chn.cognizant.com (Gururajan, Subhashini (Cognizant)) Date: Mon Jun 30 08:54:12 2003 Subject: [Expat-discuss] c++-ize expat Message-ID: <14E2ECED6A08844980C5C5C9BDD247B1016F6A1E@ctsinentsxua.cts.com> Hi, Why is it that I get junk characters in handler sometimes. Because of this the parser fails. Please help me out. It is very inconsistent. Please ... somebody.. -subha -----Original Message----- From: m. [mailto:michal017@centrum.sk] Sent: Wednesday, June 25, 2003 11:25 AM To: expat-discuss@libexpat.org Subject: Re: [Expat-discuss] c++-ize expat You know what? You are entirely right.. This information was based on my colleague's knowledge, I should have tested it before I posted a question.. My apologies michal On Tue, 24 Jun 2003 23:29:01 +0100 Graham Bennett wrote: >On Tue, Jun 24, 2003 at 02:38:21PM +0200, m. wrote: >> Hello.. I am wondering whether it is possible to c++-ize expat's code >> so that it could be compiled with c++ compiler. The reason for this >> is the ability to throw exceptions from callback functions. I have to >> remove all the 'extern "C"' stuff from expat code and cast all the >> void* to FILE* and so on.. Could this be done in the default expat's >> code? > >In order to use expat from C++ code it is not necessary to compile with >g++. All that you need is to compile with gcc with the -fexceptions >flag. This generates the necessary stack unwinding code to allow >exceptions to be thrown. > >IIRC, the expat configure script will enable the -fexceptions flag if it >detects the compiler is gcc (even though it checks for -fno-exceptions). >Try it and see. > >I have used expat from C++ code compiled in this way and I've had no >problems throwing exceptions through expat code. > >cheers, > >-- >Graham Bennett > > _______________________________________________ Expat-discuss mailing list Expat-discuss@libexpat.org http://mail.libexpat.org/mailman/listinfo/expat-discuss -------------- next part -------------- This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. Visit us at http://www.cognizant.com From michal017 at centrum.sk Mon Jun 30 17:38:02 2003 From: michal017 at centrum.sk (m.) Date: Mon Jun 30 10:38:34 2003 Subject: [Expat-discuss] c++-ize expat In-Reply-To: <14E2ECED6A08844980C5C5C9BDD247B1016F6A1E@ctsinentsxua.cts.com> References: <14E2ECED6A08844980C5C5C9BDD247B1016F6A1E@ctsinentsxua.cts.com> Message-ID: <20030630163802.11ea363f.michal017@centrum.sk> Give us an example.. m. On Mon, 30 Jun 2003 18:26:45 +0530 "Gururajan, Subhashini (Cognizant)" wrote: >Hi, >Why is it that I get junk characters in handler sometimes. Because of this the parser fails. Please help me out. It is very inconsistent. > >Please ... somebody.. > >-subha > >-----Original Message----- >From: m. [mailto:michal017@centrum.sk] >Sent: Wednesday, June 25, 2003 11:25 AM >To: expat-discuss@libexpat.org >Subject: Re: [Expat-discuss] c++-ize expat > > >You know what? You are entirely right.. >This information was based on my colleague's knowledge, I should have tested >it before I posted a question.. My apologies >michal > >On Tue, 24 Jun 2003 23:29:01 +0100 >Graham Bennett wrote: > >>On Tue, Jun 24, 2003 at 02:38:21PM +0200, m. wrote: >>> Hello.. I am wondering whether it is possible to c++-ize expat's code >>> so that it could be compiled with c++ compiler. The reason for this >>> is the ability to throw exceptions from callback functions. I have to >>> remove all the 'extern "C"' stuff from expat code and cast all the >>> void* to FILE* and so on.. Could this be done in the default expat's >>> code? >> >>In order to use expat from C++ code it is not necessary to compile with >>g++. All that you need is to compile with gcc with the -fexceptions >>flag. This generates the necessary stack unwinding code to allow >>exceptions to be thrown. >> >>IIRC, the expat configure script will enable the -fexceptions flag if it >>detects the compiler is gcc (even though it checks for -fno-exceptions). >>Try it and see. >> >>I have used expat from C++ code compiled in this way and I've had no >>problems throwing exceptions through expat code. >> >>cheers, >> >>-- >>Graham Bennett >> >> > >_______________________________________________ >Expat-discuss mailing list >Expat-discuss@libexpat.org >http://mail.libexpat.org/mailman/listinfo/expat-discuss > From marktt at excite.com Mon Jun 30 13:37:05 2003 From: marktt at excite.com (Mark Thomson) Date: Mon Jun 30 12:37:21 2003 Subject: [Expat-discuss] (no subject) Message-ID: <20030630163705.84C24B6C8@xmxpita.excite.com> I have an application which parses XML documents with some attribute values being QNames (prefix:name). I would like to be able to know which URI corresponds to the prefix. I've done this by pushing/popping pairs on/off a stack in response to calls to the StartNamespaceDeclHandler/EndNamespaceDeclHandler functions. Is it safe to just push the pointers instead of duplicating the prefix and namespace before pushing them on the stack? i.e., does expat guanartee that the pointers passed to StartNamespaceDeclHandler remain accessible until the corresponding EndNamespaceDecHandler call is made? It seems logical to assume that expat maintains a stack of pairs so that it would be able to pass a URI,sep, local name to XML_StartElementHandler. If this is correct, can anyone tell me which expat source file contains the implementaion of the stack? Does expat check whether the URI string is syntactically correct? (I don't want this to be done twice) Thanks in advance. _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From karl at waclawek.net Mon Jun 30 14:10:52 2003 From: karl at waclawek.net (Karl Waclawek) Date: Mon Jun 30 13:11:04 2003 Subject: [Expat-discuss] (no subject) References: <20030630163705.84C24B6C8@xmxpita.excite.com> Message-ID: <004201c33f2a$8fcbcba0$9e539696@citkwaclaww2k> > I have an application which parses XML documents with some attribute values being QNames (prefix:name). I would like to be able to know which URI corresponds to the prefix. I've done this by pushing/popping pairs on/off a stack in response to calls to the StartNamespaceDeclHandler/EndNamespaceDeclHandler functions. > > Is it safe to just push the pointers instead of duplicating the prefix and namespace before pushing them on the stack? i.e., does expat guanartee that the pointers passed to StartNamespaceDeclHandler remain accessible until the corresponding EndNamespaceDecHandler call is made? > > It seems logical to assume that expat maintains a stack of pairs so that it would be able to pass a URI,sep, local name to XML_StartElementHandler. If this is correct, can anyone tell me which expat source file contains the implementaion of the stack? No need to do any of that. Expat will pass the prefix if you set the NSTriplet option. Check the documentation in reference.html. > > Does expat check whether the URI string is syntactically correct? (I don't want this to be done twice) I am not sure if Expat checks the URI for conformance, and don't have the time to look at the source. Why don't you submit an incorrect URI to Expat and check the response? I am interested in the outcome. Karl From xcross at us.ibm.com Mon Jun 30 12:42:04 2003 From: xcross at us.ibm.com (Chris Cross) Date: Mon Jun 30 13:42:45 2003 Subject: [Expat-discuss] Chris Cross/West Palm Beach/IBM is out of the office. Message-ID: I will be out of the office starting June 27, 2003 and will not return until July 7, 2003. From marktt at excite.com Mon Jun 30 15:42:27 2003 From: marktt at excite.com (Mark Thomson) Date: Mon Jun 30 14:43:01 2003 Subject: [Expat-discuss] (no subject) Message-ID: <20030630184227.504413CF4@xmxpita.excite.com> > No need to do any of that. Expat will pass the prefix if you set the > NSTriplet option. I am sorry, may be I wasn't clear enough. Suppose I have an XML file containing: . . . . . . Expat can handle gg:attr2, but it cannot handle the value of attr. The type of the attribute 'attr' is QName. expat doesn't (and cannot) know that. I want to be able to determine what namespace corresponds to foo. It would be great if expat had a function to do that (e.g. const XML_Char *XML_GetNamespace(const XML_Char *prefix)), but since it doesn't, I have to do this manually by keeping track of all namespace aliases seen so far (including keeping track of the current and previous default namespaces). The obvious way to do it is to use a stack (I assume expat uses a stack internally). I want to avoid the overhead of calling 2 strdup()'s before storing a pair on the stack. This seems safe to do (not using strdup()), since expat must have the aliases stored somewhere, otherwise it won't be able to expand elements or attributes of the form alias:local-name. I just want to be sure that it's really safe, is it? Also, I want to take this one step further and avoid the overhead of having a separate stack, and access expat's stack directly instead. Can you send me info on where can I find the code that deals with storing/retrieiving pairs? (I know my code will not be portable, but efficiency is more important for me). My problem will be solved if expat had an XML_GetNamespace() function, so please consider having it in future releases. Thanks. _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From karl at waclawek.net Mon Jun 30 16:10:06 2003 From: karl at waclawek.net (Karl Waclawek) Date: Mon Jun 30 15:10:11 2003 Subject: [Expat-discuss] (no subject) References: <20030630184227.504413CF4@xmxpita.excite.com> Message-ID: <008401c33f3b$37874c60$9e539696@citkwaclaww2k> > I am sorry, may be I wasn't clear enough. > > Suppose I have an XML file containing: > > . > . > . > > > > . > . > . > > Expat can handle gg:attr2, but it cannot handle the value of attr. > > The type of the attribute 'attr' is QName. expat doesn't (and cannot) know that. I want to be able to determine what namespace corresponds to foo. It would be great if expat had a function to do that (e.g. const XML_Char *XML_GetNamespace(const XML_Char *prefix)), but since it doesn't, I have to do this manually by keeping track of all namespace aliases seen so far (including keeping track of the current and previous default namespaces). > > The obvious way to do it is to use a stack (I assume expat uses a stack internally). I want to avoid the overhead of calling 2 strdup()'s before storing a pair on the stack. This seems safe to do (not using strdup()), since expat must have the aliases stored somewhere, otherwise it won't be able to expand elements or attributes of the form alias:local-name. I just want to be sure that it's really safe, is it? Expat uses mainly linked lists for implementing stacks. Have a look at the TAG and the BINDING structure. Check xmlparse.c for the switch() code around these token constants: XML_TOK_START_TAG_WITH_ATTS XML_TOK_EMPTY_ELEMENT_WITH_ATTS XML_TOK_END_TAG and see how the code deals with "tagStack" and "tag->bindings" as well as these calls: addBinding() storeAtts() start/endElementHandler() start/endNamespaceDeclHandler It's not for the faint of heart. ;-) > Also, I want to take this one step further and avoid the overhead of having a separate stack, and access expat's stack directly instead. Can you send me info on where can I find the code that deals with storing/retrieiving pairs? (I know my code will not be portable, but efficiency is more important for me). > > My problem will be solved if expat had an XML_GetNamespace() function, so please consider having it in future releases. Don't take my word for it, but after looking at the code briefly, I think that you will need to access the current top element of tagStack and search each TAG on the stack for a matching tag->binding (going down the stack), returning the first one that matches your prefix (since there may be multiple prefix mappings). Expat relies on volunteer work, so if you find a nice way to do that, why not share it with the community? Karl