From EricBeyelerMQ@aol.com Thu Oct 05 10:48:03 2006 Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1GVXKE-0000EA-Mq for libxmlplusplus-general@lists.sourceforge.net; Thu, 05 Oct 2006 10:48:02 -0700 Received: from imo-m22.mx.aol.com ([64.12.137.3] helo=imo-m22.mail.aol.com) by mail.sourceforge.net with esmtp (Exim 4.44) id 1GVXKD-0004I5-8G for libxmlplusplus-general@lists.sourceforge.net; Thu, 05 Oct 2006 10:48:02 -0700 Received: from EricBeyelerMQ@aol.com by imo-m22.mx.aol.com (mail_out_v38_r7.6.) id 6.bff.637ae34 (45776) for ; Thu, 5 Oct 2006 13:47:46 -0400 (EDT) Received: from US105306.ad.aol.aoltw.net ([10.167.43.232]) by ciaaol-r01.mx.aol.com (v112_r1.5) with ESMTP id MAILCIAAOLR015-b2d04525454131c; Thu, 05 Oct 2006 13:47:46 -0400 Date: Thu, 5 Oct 2006 13:47:46 -0400 From: "Eric Beyeler" To: libxmlplusplus-general@lists.sourceforge.net Message-ID: <45254541.2040600@aol.com> X-Mailer: AOL Communicator (20030919.3 Win) Organization: Mapquest MIME-Version: 1.0 Content-Type: TEXT/HTML; CHARSET=us-ascii X-AOL-IP: 10.167.43.232 X-Spam-Flag: NO X-Spam-Score: 2.1 (++) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 0.0 HTML_MESSAGE BODY: HTML included in message 2.0 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 0.1 HTML_50_60 BODY: Message is 50% to 60% HTML 0.0 HTML_TITLE_EMPTY BODY: HTML title contains no text Subject: [libxml++] xml schema X-BeenThere: libxmlplusplus-general@lists.sourceforge.net X-Mailman-Version: 2.1.8 Precedence: list Reply-To: EricBeyelerMQ@aol.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2006 17:48:03 -0000 I too am wondering about plans for wrapping the xml schema functionality. This would be a big plus, (or plusplus) pardon the pun.

Eric
 From EricBeyelerMQ@aol.com Fri Oct 06 06:21:26 2006 Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1GVpdm-0002Nh-F4 for libxmlplusplus-general@lists.sourceforge.net; Fri, 06 Oct 2006 06:21:26 -0700 Received: from imo-m18.mx.aol.com ([64.12.138.208]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1GVpdl-0000kX-2c for libxmlplusplus-general@lists.sourceforge.net; Fri, 06 Oct 2006 06:21:26 -0700 Received: from EricBeyelerMQ@aol.com by imo-m18.mx.aol.com (mail_out_v38_r7.6.) id 6.590.9b20ce0 (60451) for ; Fri, 6 Oct 2006 09:21:13 -0400 (EDT) Received: from US105306.ad.aol.aoltw.net ([10.167.43.232]) by ciaaol-r01.mx.aol.com (v112_r1.5) with ESMTP id MAILCIAAOLR014-ec234526584829c; Fri, 06 Oct 2006 09:21:12 -0400 Date: Fri, 6 Oct 2006 09:21:12 -0400 From: "Eric Beyeler" To: libxmlplusplus-general@lists.sourceforge.net Message-ID: <45265848.1010606@aol.com> X-Mailer: AOL Communicator (20030919.3 Win) Organization: Mapquest MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii X-AOL-IP: 10.167.43.232 X-Spam-Flag: NO X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 Subject: [libxml++] xml schema X-BeenThere: libxmlplusplus-general@lists.sourceforge.net X-Mailman-Version: 2.1.8 Precedence: list Reply-To: EricBeyelerMQ@aol.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2006 13:21:26 -0000 (Reposting in plain text) I too am wondering about plans for wrapping the xml schema validation. This would be a big plus, (or plusplus) pardon the pun. Eric From EricBeyelerMQ@aol.com Mon Oct 09 08:53:55 2006 Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1GWxRz-0008V7-NZ for libxmlplusplus-general@lists.sourceforge.net; Mon, 09 Oct 2006 08:53:55 -0700 Received: from imo-d04.mx.aol.com ([205.188.157.36]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1GWxRy-0003ZW-CQ for libxmlplusplus-general@lists.sourceforge.net; Mon, 09 Oct 2006 08:53:55 -0700 Received: from EricBeyelerMQ@aol.com by imo-d04.mx.aol.com (mail_out_v38_r7.6.) id 6.bd0.5065eef (48369) for ; Mon, 9 Oct 2006 11:53:32 -0400 (EDT) Received: from US105306.ad.aol.aoltw.net ([10.167.43.232]) by ciaaol-r02.mx.aol.com (v112_r1.5) with ESMTP id MAILCIAAOLR026-bcf1452a707c24b; Mon, 09 Oct 2006 11:53:32 -0400 Date: Mon, 9 Oct 2006 11:53:31 -0400 From: "Eric Beyeler" To: libxmlplusplus-general@lists.sourceforge.net Message-ID: <452A707B.6000605@aol.com> X-Mailer: AOL Communicator (20030919.3 Win) Organization: Mapquest MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii X-AOL-IP: 10.167.43.232 X-Spam-Flag: NO X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 Subject: Re: [libxml++] MS Visual 2005 - Return object across DLL boundary? (Was: Another issue) X-BeenThere: libxmlplusplus-general@lists.sourceforge.net X-Mailman-Version: 2.1.8 Precedence: list Reply-To: EricBeyelerMQ@aol.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2006 15:53:56 -0000 Is there are known workaround, or proposed fix? Thanks, Eric ----Original Message---- On Wed, 2006-07-19 at 13:34 -0400, Robert S. Grimes wrote: [snip] > This seems to say the object was created on another heap (libxml++ DLL's > heap?) and being deleted by my code (using the main heap?). It seems the > "return value optimization" has been applied, and it perhaps shouldn't have > been. Does this make any sense? If so, what do I do about it? Or am I > missing something even more obvious? This looks the annoying MSVC++ requirement that memory is deallocated in the same library (DLL) in which it was allocated. So, if a library gives you a newly allocated object, you can't delete it yourself. You have to tell the library to delete it. libsigc++ used to have this same problem. You can usually fix this by making sure that, though the deletion is initiated in the caller, the actual deletion happens in some function in the library. Which would require a patch. From EricBeyelerMQ@aol.com Mon Oct 09 09:48:28 2006 Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1GWyIm-0006Gp-5a for libxmlplusplus-general@lists.sourceforge.net; Mon, 09 Oct 2006 09:48:28 -0700 Received: from imo-d22.mx.aol.com ([205.188.144.208]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1GWyIk-0002A7-QZ for libxmlplusplus-general@lists.sourceforge.net; Mon, 09 Oct 2006 09:48:28 -0700 Received: from EricBeyelerMQ@aol.com by imo-d22.mx.aol.com (mail_out_v38_r7.6.) id 6.bc9.41573ad (60450) for ; Mon, 9 Oct 2006 12:48:07 -0400 (EDT) Received: from US105306.ad.aol.aoltw.net ([10.167.43.232]) by ciaaol-r01.mx.aol.com (v112_r1.5) with ESMTP id MAILCIAAOLR013-ec22452a7d4628a; Mon, 09 Oct 2006 12:48:07 -0400 Date: Mon, 9 Oct 2006 12:48:03 -0400 From: "Eric Beyeler" To: libxmlplusplus-general@lists.sourceforge.net In-Reply-To: <452A707B.6000605@aol.com> Message-ID: <452A7D43.4020801@aol.com> References: <452A707B.6000605@aol.com> X-Mailer: AOL Communicator (20030919.3 Win) Organization: Mapquest MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii X-AOL-IP: 10.167.43.232 X-Spam-Flag: NO X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 Subject: Re: [libxml++] MS Visual 2005 - Return object across DLL boundary? (Was: Another issue) X-BeenThere: libxmlplusplus-general@lists.sourceforge.net X-Mailman-Version: 2.1.8 Precedence: list Reply-To: EricBeyelerMQ@aol.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2006 16:48:28 -0000 After looking at the code, it seems to me the fix is to have libxml++ specify an allocator object when constructing all container-based objects that are returned to the calling code. Not sure how that would need to be implemented but that would enable the vector to maintain info on how to deallocate its internal data. Eric Eric Beyeler wrote on 10/9/2006, 11:53 AM: > Is there are known workaround, or proposed fix? > > Thanks, > Eric > > ----Original Message---- > On Wed, 2006-07-19 at 13:34 -0400, Robert S. Grimes wrote: > [snip] > > This seems to say the object was created on another heap (libxml++ > DLL's > > heap?) and being deleted by my code (using the main heap?). It > seems the > > "return value optimization" has been applied, and it perhaps > shouldn't have > > been. Does this make any sense? If so, what do I do about it? > Or am I > > missing something even more obvious? > > This looks the annoying MSVC++ requirement that memory is > deallocated in > the same library (DLL) in which it was allocated. So, if a library > gives > you a newly allocated object, you can't delete it yourself. You have to > tell the library to delete it. libsigc++ used to have this same > problem. > > You can usually fix this by making sure that, though the deletion is > initiated in the caller, the actual deletion happens in some > function in > the library. Which would require a patch. > From murrayc@murrayc.com Mon Oct 09 11:53:59 2006 Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1GX0GF-0000iE-M0 for libxmlplusplus-general@lists.sourceforge.net; Mon, 09 Oct 2006 11:53:59 -0700 Received: from sd-green-bigip-207.dreamhost.com ([208.97.132.207] helo=swarthymail-a6.dreamhost.com) by mail.sourceforge.net with esmtp (Exim 4.44) id 1GX0GA-0007ug-5X for libxmlplusplus-general@lists.sourceforge.net; Mon, 09 Oct 2006 11:53:56 -0700 Received: from noname (u25-56.dsl.vianetworks.de [212.168.164.56]) by swarthymail-a6.dreamhost.com (Postfix) with ESMTP id AC64B10798C; Mon, 9 Oct 2006 11:53:20 -0700 (PDT) From: Murray Cumming To: EricBeyelerMQ@aol.com In-Reply-To: <452A7D43.4020801@aol.com> References: <452A707B.6000605@aol.com> <452A7D43.4020801@aol.com> Content-Type: text/plain Date: Mon, 09 Oct 2006 20:53:17 +0200 Message-Id: <1160419998.5581.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 Cc: libxmlplusplus-general@lists.sourceforge.net Subject: Re: [libxml++] MS Visual 2005 - Return object across DLL boundary? (Was: Another issue) X-BeenThere: libxmlplusplus-general@lists.sourceforge.net X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2006 18:53:59 -0000 On Mon, 2006-10-09 at 12:48 -0400, Eric Beyeler wrote: > After looking at the code, it seems to me the fix is to have libxml++ > specify an allocator object when constructing all container-based > objects that are returned to the calling code. Not sure how that would > need to be implemented but that would enable the vector to maintain info > on how to deallocate its internal data. That sounds quite sensible. A patch would be very welcome. -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From cdevienne@alphacent.com Tue Oct 10 06:33:55 2006 Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1GXHk3-0005AP-L7 for libxmlplusplus-general@lists.sourceforge.net; Tue, 10 Oct 2006 06:33:55 -0700 Received: from smtp1.orange.fr ([193.252.22.30] helo=smtp-msa-out01.orange.fr) by mail.sourceforge.net with esmtp (Exim 4.44) id 1GXHk2-0008B3-6q for libxmlplusplus-general@lists.sourceforge.net; Tue, 10 Oct 2006 06:33:55 -0700 Received: from mail.alphacent.com (LAubervilliers-151-11-55-32.w193-251.abo.wanadoo.fr [193.251.91.32]) by mwinf0112.orange.fr (SMTP Server) with ESMTP id 0828A1C00608 for ; Tue, 10 Oct 2006 15:33:45 +0200 (CEST) X-ME-UUID: 20061010133345336.0828A1C00608@mwinf0112.orange.fr Received: from [192.168.1.70] (luciole.alphacent.com [192.168.1.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.alphacent.com (Postfix) with ESMTP id DF6B57C9A for ; Tue, 10 Oct 2006 15:33:42 +0200 (CEST) Message-ID: <452BA118.8080000@alphacent.com> Date: Tue, 10 Oct 2006 15:33:12 +0200 From: Christophe de Vienne User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: libxmlplusplus-general@lists.sourceforge.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 1.0 FORGED_RCVD_HELO Received: contains a forged HELO Subject: [libxml++] Wanted : New maintainer for libxml++ X-BeenThere: libxmlplusplus-general@lists.sourceforge.net X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2006 13:33:55 -0000 Dear all, The past year has been pretty calm for libxml++, which is a pity considering the interesting features a lot of users are waiting for. Schema validation for example, and generally speaking a better coverage of the libxml2 API, would make libxml++ a lot more useful. Unfortunately I know I will not have time anymore to spend on libxml++. As a consequence I am willing to step down from the role of libxml++ maintainer so it can go active again. Aside from bug fixing and feature requests handling (see the project summary at http://bugzilla.gnome.org/browse.cgi?product=libxml%2B%2B), the goals I would set for the project today are : - Remain API/ABI compatible so that no existing application gets broken. - Cover more completely the libxml2 API, beginning with XML Schema validation, validation on the SaxParser, maybe TextWriter. - Keep up with the Gnome Release Schedule. If you are interested in taking this responsibility, do not hesitate to contact me privately. As a conclusion I would like to thank all the skilled developers who helped me make libxml++ what it is, and more especially Murray Cumming. I learned a lot thanks to his experience of open-source projects, and the project would not have the visibility and the high profile it has today without him. Special thanks also go to Ari Johnson, the original author of libxml++, who permitted me to live this great experience. Best regards, Christophe de Vienne From loic.joly@reportive.com Wed Oct 11 09:20:19 2006 Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1GXgoc-0002jl-34 for libxmlplusplus-general@lists.sourceforge.net; Wed, 11 Oct 2006 09:20:19 -0700 Received: from [81.80.252.137] (helo=parexc02.interne.artech.fr) by mail.sourceforge.net with smtp (Exim 4.44) id 1GXgoa-00053X-F9 for libxmlplusplus-general@lists.sourceforge.net; Wed, 11 Oct 2006 09:20:18 -0700 Date: Tue, 10 Oct 2006 09:13:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <68CDE77A191C3E40809D4CC7C42D1C9401B79201@bosphore.interne.artech.fr> From: =?iso-8859-1?Q?Lo=EFc_Joly?= To: , X-Spam-Score: 4.0 (++++) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 4.0 DATE_IN_PAST_24_48 Date: is 24 to 48 hours before Received: date Subject: Re: [libxml++] MS Visual 2005 - Return object across DLL boundary?(Was: Another issue) X-BeenThere: libxmlplusplus-general@lists.sourceforge.net X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Oct 2006 16:20:19 -0000 > Is there are known workaround, or proposed fix? >=20 > Thanks, > Eric Have you read my previous message on the subject ? I use libxml++ with = several DLL on VC++2005, and have not encountered any problems. To my understanding, there is another way to acheive this : If you select the Multi-threaded DLL (/MD) options, all = allocations/deallocations, either from the main program or from the DLL = are delegated to yet another DLL (MSVCR80.DLL) (which must then be = delivered with the program), and thus happen in a unique place. Of course, the main program and all its DLL should be compile with the = same option. -- Lo=EFc >=20 > ----Original Message---- > On Wed, 2006-07-19 at 13:34 -0400, Robert S. Grimes wrote: > [snip] > > This seems to say the object was created on another heap=20 > (libxml++ DLL's > > heap?) and being deleted by my code (using the main=20 > heap?). It seems the > > "return value optimization" has been applied, and it=20 > perhaps shouldn't have > > been. Does this make any sense? If so, what do I do=20 > about it? Or am I > > missing something even more obvious? >=20 > This looks the annoying MSVC++ requirement that memory is=20 > deallocated in > the same library (DLL) in which it was allocated. So, if a=20 > library gives > you a newly allocated object, you can't delete it yourself.=20 > You have to > tell the library to delete it. libsigc++ used to have this same > problem. >=20 > You can usually fix this by making sure that, though the deletion is > initiated in the caller, the actual deletion happens in=20 > some function in > the library. Which would require a patch. >=20 >=20 From poulpelgp@gmail.com Thu Oct 19 07:43:59 2006 Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1GaZ7n-0001e2-1P for libxmlplusplus-general@lists.sourceforge.net; Thu, 19 Oct 2006 07:43:59 -0700 Received: from wx-out-0506.google.com ([66.249.82.233]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1GaZ7m-0001oo-7d for libxmlplusplus-general@lists.sourceforge.net; Thu, 19 Oct 2006 07:43:59 -0700 Received: by wx-out-0506.google.com with SMTP id i30so562668wxd for ; Thu, 19 Oct 2006 07:43:57 -0700 (PDT) Received: by 10.70.23.1 with SMTP id 1mr18492624wxw; Thu, 19 Oct 2006 07:43:57 -0700 (PDT) Received: by 10.70.44.18 with HTTP; Thu, 19 Oct 2006 07:43:57 -0700 (PDT) Message-ID: <3e7c129b0610190743waa66d85if7b4235992e45f04@mail.gmail.com> Date: Thu, 19 Oct 2006 10:43:57 -0400 From: Poulpe To: libxmlplusplus-general@lists.sourceforge.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_162722_30571507.1161269037680" X-Spam-Score: 0.2 (/) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 0.0 RCVD_BY_IP Received by mail server with no name 0.0 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_00_10 BODY: Message is 0% to 10% HTML Subject: [libxml++] DTD Directory and Default attribute from DTD X-BeenThere: libxmlplusplus-general@lists.sourceforge.net X-Mailman-Version: 2.1.8 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2006 14:43:59 -0000 ------=_Part_162722_30571507.1161269037680 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Everyboby. I'm just starting to use libxml++ for a research project (migrating form XERCES-C whose license is "supposed" to be GPL compatible, but the Apache Software Foundation is still not sure...). For now, i just use the DOM parser to read a file and browsing the resulting tree. I have two issues: * directory issue when memory parsing : the directory associated to a parse when memory/stream parsing is processed: if the DTD referenced in xml definition in memory is not in the working directory, a "file not found" exception is launched. I have corrected this issue in my code by rewriting a parse_memory() method, adding a directory parameter and: > context_->directory = (char*) xmlStrdup((xmlChar*)directory); just before the parse_context() call (maybe a preprocessing is needed on char* directory in order to extract the directory from the entire file path) Maybe it could be interesting to add this kind of features in the code * default attribute value form DTD When I parse a validated XML file with DOMParser, and i browse the resulting tree, calls to get_attribute(name) returns NULL when the attribute is not present in the XML, but has a default value in DTD. I don't if it is a normal behavior or if i forget to set some option (currently using set_validate() and set_substitute_entities()). If it's a normal behavior, it could be interesting to add a fonction to get the value, defaulted if not present in XML. For now, i use a libxml call to xmlGetProp() instead of the xmlHasProp(). This returns a char string if attribute is present or defaulted, else returns NULL. Please say if i get wrong somewhere. Best regards, Raphael. ------=_Part_162722_30571507.1161269037680 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Everyboby.

I'm just starting to use libxml++ for a research project (migrating form XERCES-C whose license is "supposed" to be GPL compatible, but the Apache Software Foundation is still not sure...).
For now, i just use the DOM parser to read a file and browsing the resulting tree.
I have two issues:

* directory issue when memory parsing :
the directory associated to a parse when memory/stream parsing is processed: if the DTD referenced in xml definition in memory is not in the working directory, a "file not found" exception is launched.
I have corrected this issue in my code by rewriting a parse_memory() method, adding a directory parameter and:
> context_->directory = (char*) xmlStrdup((xmlChar*)directory);
just before the parse_context() call (maybe a preprocessing is needed on char* directory in order to extract the directory from the entire file path)
Maybe it could be interesting to add this kind of features in the code

* default attribute value form DTD
When I parse a validated XML file with DOMParser, and i browse the resulting tree, calls to get_attribute(name) returns NULL when the attribute is not present in the XML, but has a default value in DTD. I don't if it is a normal behavior or if i forget to set some option (currently using set_validate() and set_substitute_entities()).
If it's a normal behavior, it could be interesting to add a fonction to get the value, defaulted if not present in XML. For now, i use a libxml call to xmlGetProp() instead of the xmlHasProp(). This returns a char string if attribute is present or defaulted, else returns NULL.

Please say if i get wrong somewhere.

Best regards,

Raphael.
------=_Part_162722_30571507.1161269037680--