DO NOT REPLY [Bug 18594] - DOMWriter does not recognize Document Fragment

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 18594] - DOMWriter does not recognize Document Fragment

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 18594] New: - DOMWriter does not recognize Document Fragment

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: Implementing getTextContent

Hi all, What about another overload which allows for a user-supplied buffer for the text, along with an argument which specifies the maximum numbers of characters to copy, returning the number of characters actually copied? That, along with an implementation that would allow passing in a null

Re: DOMWriter->writeNode with DocumentFragment

Would you please open a bugzilla report on this? thanks. Rgds, PeiYong - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, April 01, 2003 6:06 PM Subject: DOMWriter->writeNode with DocumentFragment > When I try to "get XML" on a DOMDocumentFragment the

RE: LAX Validation

Actually I do not understand how multiple schema locations can be specified and also multiple nonamespace locations. Is setExternalSchemaLocation a URI or a flag? I could have a document validating against a.dtd, b.xsd, c.xsd(namespace X), d.xsd(namespace Y). What I want to do is I have all these

Re: LAX Validation

Hi Kiran, For question 1, I'm not sure I follow what you need. Are you after some kind of feature that will validate an element if it can find a declaration for that element, but ignore it if it can't? i.e., if your schema has global element a, b, and c, no local element decls, and your document

DOMWriter->writeNode with DocumentFragment

When I try to "get XML" on a DOMDocumentFragment the DOMWriter->writeNode() returns: Unrecognized Node Type Should I be able to get the content of a document fragment? Once I append the docfrag to a document the writeNode will show it in the contents. But when I try to peform this action on a D

RE: Implementing getTextContent

Hi Erik and Gareth, FWIW, I'm fairly strongly of the view that we need to preserve consistency here so that the parser owns this memory. It's always bad to be inconsistent but isn't it especially bad with things as subtle as memory management? Besides, the memory here is no larger than the sum o

fix for the personal.xsd sample

Hi folks, When the xml:base support was added to the parser, a means for testing that support was found by integrating xml:base attributes into the personal-schema.xml sample. While this is good in itself (testing is always good :) ), the trouble is that personal.xsd wasn't modified to permit the

LAX Validation

1. Is there any way I could run the parser with Lax validation. I just want to ignore elements which are not a part of the schema. I know schemas allows the 'any' content with lax validation. I am looking for something more general than that. 2. Is there a way I could force the parser to ONLY use

DO NOT REPLY [Bug 18542] - Deleting something returned by XMLString::transcode crashes when application is using the release build of Xerces-C++

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 18542] - Deleting something returned by XMLString::transcode crashes when application is using the release build of Xerces-C++

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: Implementing getTextContent

Hi, OK, I understand now. I was confused by the name attribute node, I thought it was part of the DOM tree, but I saw you get the attributes separately through DOMAttr* DOMElement::getAttributeNode ( const XMLCh *name ) which is logical. Magnus -Original Message- From: Erik Ryd

RE: Implementing getTextContent

> I agree, I like consistency. > Let's register the string into the document by allocating the memory on the > documents heap. > Although, the result can be very large. Should we allow the user to release > the memory when not used anymore? How? Yes, this is a potential problem. We have no way of

RE: Implementing getTextContent

I agree, I like consistency. Let's register the string into the document by allocating the memory on the documents heap. Although, the result can be very large. Should we allow the user to release the memory when not used anymore? How? / Erik -Original Message- From: Gareth Reakes [mailto

RE: Implementing getTextContent

No you must have misunderstood. As I understand the list it should be like this. For ELEMENT_NODE, ENTITY_NODE, ENTITY_REFERENCE_NODE, DOCUMENT_FRAGMENT_NODE the documentation says: Concatenation of the textContent attribute value of every child node, excluding COMMENT_NODE and PROCESSING_INSTRUC

RE: Implementing getTextContent

Hi, there are no other methods in the DOM interface that you have to do that with. My opinion is that we allow the document to manage this as well for consistency. Anyone else got an opinion? Gareth -- Gareth Reakes, Head of Product Development +44-1865-203192 DecisionSoft Limited

RE: Implementing getTextContent

Hi, > Do you know why attribute nodes should be included? They should not. > Does this XML-fragments chapter element have an > attribute node as a child? > Intro No. > If so, getTextContent would return "123Intro", seems strange? I agree that would be strange :) The only circumstance when

RE: Implementing getTextContent

Hi, Is it a problem that the caller has to delete the returned string? If it is like below, the caller owns the returned string and then perhaps it should return a XMLCh* instead of const XMLCh*? Magnus // alpha version const XMLCh* DOMNodeImpl::getTextContent() const { DOMNode*

RE: Implementing getTextContent

Hi, Do you know why attribute nodes should be included? I have just started using DOM. Does this XML-fragments chapter element have an attribute node as a child? Intro If so, getTextContent would return "123Intro", seems strange? Magnus -Original Message- From: Gareth Reakes [mailt