parse the input xml string

I want to parse the input xml string instead of xmlfile. Is there any method available in the DOM builder? I look forward to hearing from you. Thanks Prasad __ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site

Re: Memory Leak in createDocumentType() ???

Hey Jason, Jason E. Stewart wrote: According to the docs: Users must call the release() function when finished using any objects that were created by the DOMImplementation::create (e.g. DOMBuilder, DOMWriter, DOMDocument, DOMDocumentType). So here is the code: XMLCh xfoo[]

Re: Validating XSD(s)

Hi Elisha, I wrote a blog entry on this a little while ago. Take a look at http://blog.parthenoncomputing.com/xerces/archives/2005/04/can_i_validate.html Cheers, Gareth Elisha Berns wrote: Gareth, Thanks for the correction. So how do you suggest for xsd validation (without an

Re: Using delete() instead of release()

Radovan Chytracek [EMAIL PROTECTED] writes: I do not know details of Perl binding for Xerces-C but I think the DOM document could be exposed via a handle in form of smart pointer which can call transparently the release() method in its destructor. Some sort of handle-body design pattern might

Re: Validating XSD(s)

Gareth Reakes wrote: blog.parthenoncomputing.com/xerces/archives/2005/04/can_i_validate.ht ml Hi Gareth, $ ping blog.parthenoncomputing.com ping: unknown host blog.parthenoncomputing.com Is your blog server down? Axel -- Humboldt-Universität zu Berlin Institut für

Re: Using delete() instead of release()

Hey, Wrote a short one http://blog.parthenoncomputing.com/xerces/archives/2005/05/memory_manageme.html Please give comments. This comes up now and again so its worth spending a bit of time on to make it understandable. Gareth Jason E. Stewart wrote: Radovan Chytracek [EMAIL

RE: Using delete() instead of release()

Gareth, Thanks for the blog entry; however, it too is less than clear. You write, To release all memory consumed then you must delete the document. If, after deleting the document you still see a memory leak then there may well be a memory leak. What exactly does deleting the document mean in

RE: Validating XSD(s)

Gareth, Thanks for the reply and the blog entry, it's a good idea. Well my question again is how best to use Xerces to validate XSDs? What isn't clear from the blog is the degree of fuzziness involved when Xerces does successfully 1) load an XSD schema, 2) load an XML document that has a schema

Re: Validating XSD(s)

Hey Elisha, Elisha Berns wrote: Well my question again is how best to use Xerces to validate XSDs? What isn't clear from the blog is the degree of fuzziness involved when Xerces does successfully 1) load an XSD schema, 2) load an XML document that has a schema when full schema checking is

Re: Validating XSD(s)

Elisha Berns [EMAIL PROTECTED] writes: But my question is, once again, assuming that you are only using Xerces, what is the best and most thorough way to validate an XSD? Alright, seeing that you are asking this 10th time I will take a shot. In my code I do basically the following: //

Re: Using delete() instead of release()

Hey, Elisha Berns wrote: Gareth, Thanks for the blog entry; however, it too is less than clear. You write, I will clean up the language. To release all memory consumed then you must delete the document. If, after deleting the document you still see a memory leak then there may well be a

Re: Validating XSD(s)

Hi Elisha, The code Boris has looks pretty much optimal to me. Rest assured that lots of work went into Xerces-C to enable it to verify the validity of schema documents, both as per the constraints in the Schema for Schemas and the language in the Rec. You might also want to take a look at

importNode crashes

Hi , Here is my code, .. DOMDocument* Domdoc = (DOMDocument*)theLiaisonPtr-mapToXercesDocument(theDocumentPtr);XalanDocument *Xalandoc = theLiaisonPtr-createDocument(Domdoc,false,true,true);XalanNode * root_context_node = Xalandoc;XalanElement *namespace_node =

RE: Validating XSD(s)

Gareth, Thanks for the additional comments, it's good to know what the actual developers of a tool think about it! Your comments beg the question what other schema standard looks better than XSD at this point, Relax?, Schematron constraints? And are there any plans for Xerces to support

Re: importNode crashes

Why cant I do an import of the node ? This is a Xalan-C++ question, not a Xerces-C question. You are posting on the wrong list. The crash is because you are not catching the appropriate exception that the Xalan-C++ wrapper class is throwing. You cannot use the mutating functions of the

Re: Validating XSD(s)

Elisha Berns [EMAIL PROTECTED] writes: I can't figure out two things in your code: parser-setFeature (XMLUni::fgDOMNamespaces, true); I only see a feature called fgSAX2CoreNameSpaces for the SAX2XMLReader interface, what interface are you using? Or what interface does this feature

[jira] Commented: (XERCESC-1420) XMLPlatformUtils::makeMutex() creates mutex objects using the C++ runtime heap instead of using a MemoryManager instance

[ http://issues.apache.org/jira/browse/XERCESC-1420?page=comments#action_66387 ] James Berry commented on XERCESC-1420: -- Hey Dave, I fixed up something similar (I believe) in my work on Xerces 3.0 at

[jira] Commented: (XERCESC-1420) XMLPlatformUtils::makeMutex() creates mutex objects using the C++ runtime heap instead of using a MemoryManager instance

[ http://issues.apache.org/jira/browse/XERCESC-1420?page=comments#action_66390 ] David Bertoni commented on XERCESC-1420: Sure, I'll take a look. By the way, I should be attaching a patch containing my fixes to this bug report later today.

Invalid character 0xFFFe

Hi, All, I am encounting a XML parsing error saying something like the following: XML Parser failed, Error: Invalid character (Unicode 0xFFFe) The XML filesize is about100K in disk, the application is sort of like this: it is createdfrom a DOM tree in memory then passed to a SAX

RE: Invalid character 0xFFFe

Thanks much for the reply. But in my case, the XML is created in memory, and I don't see the BOM char at the beginning when I look at it in memory in debugger, in fact, I don't see FFFE at all in memory. Also, if I make the XML smaller, then everything works fine. So I wouild think that the

RE: Invalid character 0xFFFe

Matt, That's what I did, and I couldn't find FFFE at all. BTW, I am using Xerces-c 1.7, could that be a problem? Thanks. Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, May 26, 2005 2:52 PM To: c-dev@xerces.apache.org Subject: RE: Invalid

RE: Invalid character 0xFFFe

Ack! Please do not use outdated versions of Xerces libraries. It makes it difficult to assure you that your problem is not some sort of bug. First I would try upgrading. If upgrading does not work, perhaps you could search the user and dev lists for FFFE and FEFF, as well as trying the

RE: Validating XSD(s)

Boris, Thanks for the clarification. Elisha Berns [EMAIL PROTECTED] writes: I can't figure out two things in your code: parser-setFeature (XMLUni::fgDOMNamespaces, true); I only see a feature called fgSAX2CoreNameSpaces for the SAX2XMLReader interface, what interface are you

RE: Invalid character 0xFFFe

I debugged into the Xerces library code (compiled with the src) and found out that the problem is that my in-memory XML is too big! It was actually small, only about 20K something, but the XMLReader that Xerces library creates for me has a fCharBuf of constant size 16*1024, and when I created a

RE: Invalid character 0xFFFe

I debugged into the Xerces library code (compiled with the src) and found out that the problem is that my in-memory XML is too big! It was actually small, only about 20K something, but the XMLReader that Xerces library creates for me has a fCharBuf of constant size 16*1024, and when I created

[jira] Assigned: (XERCESC-1348) IGXMLScanner allocates from wrong memory manager

[ http://issues.apache.org/jira/browse/XERCESC-1348?page=all ] David Bertoni reassigned XERCESC-1348: -- Assign To: David Bertoni IGXMLScanner allocates from wrong memory manager Key:

[jira] Updated: (XERCESC-1348) IGXMLScanner allocates from wrong memory manager

[ http://issues.apache.org/jira/browse/XERCESC-1348?page=all ] David Bertoni updated XERCESC-1348: --- Attachment: patch.txt Mark, if you're still there, can you review this patch? Thanks! IGXMLScanner allocates from wrong memory manager

RE: Fw: Building Xerces 2.3.0 with GCC 3.4.2 on Solaris5.8!!!

Hi Matthew I did try building with the acrhive link info. The configure does recognise sparc64-sun-solaris2.8 but ends up creating a 32 bit ELF xerces. The 64 bit flags are showing up on compilation but not effective! I guess you meant that we can build only 32 bit xerces with GCC on Solaris?