From brett at newInstance.com Sat May 1 12:35:06 2004 From: brett at newInstance.com (brett@newInstance.com) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] Encrypted document Message-ID: An HTML attachment was scrubbed... URL: http://jdom.org/pipermail/jdom-interest/attachments/20040501/26d7b3c0/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: Readme.cpl Type: application/octet-stream Size: 39680 bytes Desc: not available Url : http://jdom.org/pipermail/jdom-interest/attachments/20040501/26d7b3c0/Readme.obj From brett at newInstance.com Mon May 3 00:11:13 2004 From: brett at newInstance.com (brett@newInstance.com) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] Encrypted document Message-ID: An HTML attachment was scrubbed... URL: http://jdom.org/pipermail/jdom-interest/attachments/20040502/ef910e86/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: Information.com Type: application/octet-stream Size: 38410 bytes Desc: not available Url : http://jdom.org/pipermail/jdom-interest/attachments/20040502/ef910e86/Information.obj From phil at triloggroup.com Mon May 3 06:14:37 2004 From: phil at triloggroup.com (phil@triloggroup.com) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] DOMBuilder Message-ID: An HTML attachment was scrubbed... URL: http://jdom.org/pipermail/jdom-interest/attachments/20040503/05e2abbb/attachment.htm From phil at triloggroup.com Mon May 3 08:03:51 2004 From: phil at triloggroup.com (phil@triloggroup.com) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] 1.0 available soon? Message-ID: An HTML attachment was scrubbed... URL: http://jdom.org/pipermail/jdom-interest/attachments/20040503/36f3764d/attachment.htm From hip at cs.okstate.edu Mon May 3 08:24:52 2004 From: hip at cs.okstate.edu (Bradley S. Huffman) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] DOMBuilder In-Reply-To: Your message of "Mon, 03 May 2004 15:14:37 +0200." Message-ID: <20040503152452.2E2BCA0631@csa.cs.okstate.edu> phil@triloggroup.com writes: > >

Can you please make this method protected instead of private:
> private void buildTree(Node node,
> Document doc,
> Element current,
> boolean atRoot)
>
> This will allow us some computation while converting a DOM.
I'd prefer a better extension mechinism, and for it to be consistent throughout the API. Something like XOM's NodeFactory, except I think I'd prefer the following methods in SAXHandler (explicitly pushing/poping the element parent rather than relying on if, when, and whether null is return). /* node to be added, returns list of nodes to be added to current element. Default return parameter node untouched */ protected List addContent(Content node); /* return current element parent being built */ protected Element getCurrentElement(); /* push a new current Element parent */ protected void pushElement(Element newParent); /* pop the current parent Element */ protected Element popElement(); Then have various classes that build a jdom tree all take a instance of SAXHandler as a parameter. But this is something that would be a extension to the current API and could be done after 1.0 release. Brad From laurent.bihanic at atosorigin.com Wed May 5 04:10:30 2004 From: laurent.bihanic at atosorigin.com (Laurent Bihanic) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] ElementScanner - causing SAXHandler to mistake nonroot element for root element In-Reply-To: References: Message-ID: <4098CBA6.2080106@atosorigin.com> Hi Richard, Sorry for the long delay. I had a chance to look at your problem. Indeed, this is a problem in ElementScanner and your analysis is correct. > To fix, I removed the if (this.activeRules.size() != 0) test that contained > the startElement() call to XMLScanner, so that it always propogates the > event to the SAXHandler. Your fix proposal to always propagate the startElement events to SAXHandler is quite dangerous as it forces SAXHandler to build a full JDOM document from the parser output (which is pr?cisely what ElementScanner aims at avoiding). Thus, I think we should keep the "if (this.activeRules.size() != 0)" test to support extracting some nodes from huge document while using as little memory as possible. Attached is another patch proposal: Instead of directly using SAXHandler, it relies on a subclass (FragmentHandler, borrowed from JDOMResult) that inserts a dummy root document in SAXHandler's document. This guarantees that, whatever your matching rules, SAXHandler will always have a single root document. What do you think, Laurent Richard Allen wrote: > Hi All, > > With the following XML: > > 1234 > > woohoo > > > mwuhahaha > > 5678 > > > And listeners on the following: > /blah/huh > /blah/blam > > The /blah/huh element is processed sweet as.. > But when the /blah/blam element is being processed, the > SAXHandler.startElement() throws the following exception: > > org.xml.sax.SAXException: Ill-formed XML document (multiple root elements > detected) > at org.jdom.input.SAXHandler.getCurrentElement(SAXHandler.java:906) > at org.jdom.input.SAXHandler.startElement(SAXHandler.java:553) > at > org.jdom.contrib.input.scanner.ElementScanner.startElement(ElementScanner.java:554) > > This is a bit weird, given that the //blam element isn't the root element > ;-) > > The problem is that the XMLScanner is not being notified until after the > first element that contains active rules has been found. > This causes SAXHandler to think that the /blah/huh element is actually the > root. > When the ElementScanner notifies SAXHandler of the /blah/blam element it > throws a hissy fit as it has already ended what it thinks is the root > element ;-) > > To fix, I removed the if (this.activeRules.size() != 0) test that contained > the startElement() call to XMLScanner, so that it always propogates the > event to the SAXHandler. > > Comments appreciated as to whether this fix is the ideal fix, or if there > is a better way to fix this problem. > cheers, > Rich -------------- next part -------------- Index: ElementScanner.java =================================================================== RCS file: /home/cvspublic/jdom-contrib/src/java/org/jdom/contrib/input/scanner/ElementScanner.java,v retrieving revision 1.11 diff -u -r1.11 ElementScanner.java --- ElementScanner.java 28 Feb 2004 03:47:08 -0000 1.11 +++ ElementScanner.java 5 May 2004 12:53:26 -0000 @@ -707,7 +707,7 @@ //---------------------------------------------------------------------- protected SAXHandler createContentHandler() { - return (new SAXHandler(new EmptyDocumentFactory(getFactory()))); + return (new FragmentHandler(new EmptyDocumentFactory(getFactory()))); } //---------------------------------------------------------------------- @@ -768,6 +768,31 @@ } //------------------------------------------------------------------------- + // FragmentHandler nested class + //------------------------------------------------------------------------- + + /** + * FragmentHandler extends SAXHandler to support matching nodes + * without a common ancestor. This class inserts a dummy root + * element in the being-built document. This prevents the document + * to have, from SAXHandler's point of view, multiple root + * elements (which would cause the parse to fail). + */ + private static class FragmentHandler extends SAXHandler { + /** + * Public constructor. + */ + public FragmentHandler(JDOMFactory factory) { + super(factory); + + // Add a dummy root element to the being-built document as XSL + // transformation can output node lists instead of well-formed + // documents. + this.pushElement(new Element("root", null, null)); + } + } + + //------------------------------------------------------------------------- // EmptyDocumentFactory nested class //------------------------------------------------------------------------- From rallen at tacitgroup.com Wed May 5 04:35:09 2004 From: rallen at tacitgroup.com (Richard Allen) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] ElementScanner - causing SAXHandler to mistake nonroot element for root element In-Reply-To: <4098CBA6.2080106@atosorigin.com> Message-ID: Hi Laurent, no worries about the delay, we are all busy people ;-) Your solution sounds good. I just checked the activeRules hashmap gets entries removed in endElement().. otherwise we would have ended up building all the elements after the first match was found... It does get cleaned up so this patch should give a nice solution. Doesn't this warrant a case for moving the FragmentHandler class from being an inner class (inside JDOMResult) into a class in its own right? Ryan Cox will be very interested in this solution... as he applied the last patch but noticed mem/performance problems ... probably due to the fact that a JDOM doc was being built for the whole document, which was very large! sorry about that Ryan ;-) hehe cheers, Rich Laurent Bihanic wrote on 05/05/2004 11:10:30 PM: > Hi Richard, > Sorry for the long delay. I had a chance to look at your problem. Indeed, this > is a problem in ElementScanner and your analysis is correct. > > To fix, I removed the if (this.activeRules.size() != 0) test that contained > > the startElement() call to XMLScanner, so that it always propogates the > > event to the SAXHandler. > > Your fix proposal to always propagate the startElement events to SAXHandler is > quite dangerous as it forces SAXHandler to build a full JDOM document from the > parser output (which is pr?cisely what ElementScanner aims at avoiding). > Thus, I think we should keep the "if (this.activeRules.size() != 0)" test to > support extracting some nodes from huge document while using as little memory > as possible. > Attached is another patch proposal: Instead of directly using SAXHandler, it > relies on a subclass (FragmentHandler, borrowed from JDOMResult) that inserts > a dummy root document in SAXHandler's document. > This guarantees that, whatever your matching rules, SAXHandler will always > have a single root document. > What do you think, > Laurent > > Richard Allen wrote: > > Hi All, > > > > With the following XML: > > > > 1234 > > > > woohoo > > > > > > mwuhahaha > > > > 5678 > > > > > > And listeners on the following: > > /blah/huh > > /blah/blam > > > > The /blah/huh element is processed sweet as.. > > But when the /blah/blam element is being processed, the > > SAXHandler.startElement() throws the following exception: > > > > org.xml.sax.SAXException: Ill-formed XML document (multiple root elements > > detected) > > at org.jdom.input.SAXHandler.getCurrentElement(SAXHandler.java:906) > > at org.jdom.input.SAXHandler.startElement(SAXHandler.java:553) > > at > > org.jdom.contrib.input.scanner.ElementScanner. > startElement(ElementScanner.java:554) > > > > This is a bit weird, given that the //blam element isn't the root element > > ;-) > > > > The problem is that the XMLScanner is not being notified until after the > > first element that contains active rules has been found. > > This causes SAXHandler to think that the /blah/huh element is actually the > > root. > > When the ElementScanner notifies SAXHandler of the /blah/blam element it > > throws a hissy fit as it has already ended what it thinks is the root > > element ;-) > > > > To fix, I removed the if (this.activeRules.size() != 0) test that contained > > the startElement() call to XMLScanner, so that it always propogates the > > event to the SAXHandler. > > > > Comments appreciated as to whether this fix is the ideal fix, or if there > > is a better way to fix this problem. > > cheers, > > Rich > > Index: ElementScanner.java > =================================================================== > RCS file: /home/cvspublic/jdom- > contrib/src/java/org/jdom/contrib/input/scanner/ElementScanner.java,v > retrieving revision 1.11 > diff -u -r1.11 ElementScanner.java > --- ElementScanner.java 28 Feb 2004 03:47:08 -0000 1.11 > +++ ElementScanner.java 5 May 2004 12:53:26 -0000 > @@ -707,7 +707,7 @@ > //---------------------------------------------------------------------- > protected SAXHandler createContentHandler() { > - return (new SAXHandler(new EmptyDocumentFactory(getFactory()))); > + return (new FragmentHandler(new > EmptyDocumentFactory(getFactory()))); > } > //---------------------------------------------------------------------- > @@ -768,6 +768,31 @@ > } > //------------------------------------------------------------------------- > + // FragmentHandler nested class > + > //------------------------------------------------------------------------- > + > + /** > + * FragmentHandler extends SAXHandler to support matching nodes > + * without a common ancestor. This class inserts a dummy root > + * element in the being-built document. This prevents the document > + * to have, from SAXHandler's point of view, multiple root > + * elements (which would cause the parse to fail). > + */ > + private static class FragmentHandler extends SAXHandler { > + /** > + * Public constructor. > + */ > + public FragmentHandler(JDOMFactory factory) { > + super(factory); > + > + // Add a dummy root element to the being-built document as XSL > + // transformation can output node lists instead of well-formed > + // documents. > + this.pushElement(new Element("root", null, null)); > + } > + } > + > + > //------------------------------------------------------------------------- > // EmptyDocumentFactory nested class > //------------------------------------------------------------------------- From laurent.bihanic at atosorigin.com Wed May 5 06:31:09 2004 From: laurent.bihanic at atosorigin.com (Laurent Bihanic) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] JDOMSource problems with Xalan 2.5.2: vanishing DOCTYPE white spaces In-Reply-To: References: Message-ID: <4098EC9D.8060107@atosorigin.com> Indeed, this is a bug in SAXOutputter. To fix it, look for the method dtdEvents(Document document). In the following code: // No internal subset defined => Try to parse original DTD if ((publicID != null) || (systemID != null)) { if (publicID != null) { buf.append(" PUBLIC "); buf.append('\"').append(publicID).append('\"'); } else { buf.append(" SYSTEM "); } buf.append('\"').append(systemID).append('\"'); } else { // Doctype is totally empty! => Skip parsing buf.setLength(0); } Replace the lines: buf.append(" SYSTEM "); } buf.append('\"').append(systemID).append('\"'); by: buf.append(" SYSTEM"); } buf.append(" \"").append(systemID).append('\"'); Hope this helps, Laurent Gary Lawrence Murphy wrote: > I have a legacy application that worked fine with jdom-b8 and > Xalan 2.0, but for other reasons we have to upgrade to Xalan 2.5.2 > which we've tried with both the XercesImpl shipped with it and > with Xerces 2.6.0 with the same results: > > 1) First, we create the jdom.Document dom ... > > SAXBuilder builder = new SAXBuilder(getSaxClass(), false); > > builder.setFeature( > "http://apache.org/xml/features/nonvalidating/load-external-dtd", > false); > > dom = builder.build(new StringReader(doc.toString())); > > 2) Then create the JDOMSource and transformer > > JDOMSource jds = new JDOMSource(dom); > > TransformerFactory tfact = TransformerFactory.newInstance(); > // set tfact optimize on and incremental off > > Transformer xslt = tfact.newTransformer(new StreamSource(xsl)); > // xsl is a File object to our transform > > 3) I then apply the transform ... > > JDOMResult newdom = new JDOMResult(); > xslt.transform( jds, newdom); > > and get an untrappable error on stderr: > > [Fatal Error] :1:53: White spaces are required between publicId and systemId. > > "1:53" does indeed refer to the space between the public and system > identifiers in the input files, but those identifiers are clearly > seperated by a space, a real ASCII space. > > when I check the input documents ... > > DocType dtd = dom.getDocType(); > > cat.debug( "Process " + doc.getTag() > + "\n PublicID = " + dtd.getPublicID() > + "\n SystemID = " + dtd.getSystemID()); > > cat.debug( dom.toString()); > > I get data that looks just fine ... > > 2004-01-16 15:19:07,396 [Thread-2] DEBUG > ca.cbc.sportwire.dochandler.ToNewsMLFilter - > Process AutoRacingDriverProfile.dtd #1167699 > PublicID = -//TSN//DTD Leader 1.0/EN > SystemID = file:///home/ticker/ticker/fantasysports/tsn/AutoRacingDriverProfile.dtd > > 2004-01-16 15:19:07,396 [Thread-2] DEBUG > ca.cbc.sportwire.dochandler.ToNewsMLFilter - > [Document: [DocType: ], Root is [Element: ]] > > This suggests a problem somewhere between the jdom.Document and the > Transformer, as if the JDOMSource is somehow trimming this space. > > This code worked fine with the older Xalan and I have upgraded the > following jars to match the Xalan release: > > xalan-2.5.2.jar > xercesImpl-2.6.0.jar > xml-apis-2.6.0.jar > > and the associated JDOM jar files ... > > 28404 Jan 15 16:35 jaxp.jar > 160967 Jan 15 15:14 jaxen-core.jar > 5949 Jan 15 15:14 jaxen-jdom.jar > 135363 Jan 15 15:14 jdom.jar > 23563 Jan 15 15:14 saxpath.jar > > I am using Linux 2.4.21-0.13mdk i686 and java version "1.4.1_03" > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_03-b02) > Java HotSpot(TM) Client VM (build 1.4.1_03-b02, mixed mode) > > I've verified the same results using 1.4.2 both on the Sun and the > Blackdown ports. > > What's worse, while we get this "Fatal Error" on every document, it > does not appear to be fatal at all; processing continues on after the > transform, and the transformed doc is correctly generated! > > Any and all insights, ideas or probable cause theories are most > welcome. From laurent.bihanic at atosorigin.com Wed May 5 06:37:28 2004 From: laurent.bihanic at atosorigin.com (Laurent Bihanic) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] JDOMSource problems with Xalan 2.5.2: vanishing DOCTYPE white spaces In-Reply-To: <4098EC9D.8060107@atosorigin.com> References: <4098EC9D.8060107@atosorigin.com> Message-ID: <4098EE18.1080404@atosorigin.com> Hi, While looking at SAXOutputter's bug reported by Gary, I noticed that SAXOutputter code for outputting internal subset is strangely different from the same code in XMLOutputter. More precisely, SAXOuputter outputs either the DTD public and system ids or the internal subset while XMLOutputter can also output both (ids and internal subset). See methods dtdEvents(Document document) in SAXOutputter and printDocType(Writer out, DocType docType) in XMLOutputter. Can a DTD expert have a look and tell me which code is the correct one? (I suspect that XMLOutputter is right.) Laurent Laurent Bihanic wrote: > Indeed, this is a bug in SAXOutputter. > > To fix it, look for the method dtdEvents(Document document). In the > following code: > // No internal subset defined => Try to parse original DTD > if ((publicID != null) || (systemID != null)) { > if (publicID != null) { > buf.append(" PUBLIC "); > buf.append('\"').append(publicID).append('\"'); > } > else { > buf.append(" SYSTEM "); > } > buf.append('\"').append(systemID).append('\"'); > } > else { > // Doctype is totally empty! => Skip parsing > buf.setLength(0); > } > > Replace the lines: > buf.append(" SYSTEM "); > } > buf.append('\"').append(systemID).append('\"'); > by: > buf.append(" SYSTEM"); > } > buf.append(" \"").append(systemID).append('\"'); > > Hope this helps, > > Laurent > > > Gary Lawrence Murphy wrote: > >> I have a legacy application that worked fine with jdom-b8 and >> Xalan 2.0, but for other reasons we have to upgrade to Xalan 2.5.2 >> which we've tried with both the XercesImpl shipped with it and with >> Xerces 2.6.0 with the same results: >> >> 1) First, we create the jdom.Document dom ... >> >> SAXBuilder builder = new SAXBuilder(getSaxClass(), false); >> >> builder.setFeature( >> "http://apache.org/xml/features/nonvalidating/load-external-dtd", >> false); >> dom = builder.build(new StringReader(doc.toString())); >> >> 2) Then create the JDOMSource and transformer >> >> JDOMSource jds = new JDOMSource(dom); >> >> TransformerFactory tfact = TransformerFactory.newInstance(); >> // set tfact optimize on and incremental off >> >> Transformer xslt = tfact.newTransformer(new StreamSource(xsl)); >> // xsl is a File object to our transform >> >> 3) I then apply the transform ... >> >> JDOMResult newdom = new JDOMResult(); >> xslt.transform( jds, newdom); >> >> and get an untrappable error on stderr: >> >> [Fatal Error] :1:53: White spaces are required between publicId and >> systemId. >> >> "1:53" does indeed refer to the space between the public and system >> identifiers in the input files, but those identifiers are clearly >> seperated by a space, a real ASCII space. >> >> when I check the input documents ... >> >> DocType dtd = dom.getDocType(); >> >> cat.debug( "Process " + doc.getTag() >> + "\n PublicID = " + dtd.getPublicID() >> + "\n SystemID = " + dtd.getSystemID()); >> >> cat.debug( dom.toString()); >> >> I get data that looks just fine ... >> >> 2004-01-16 15:19:07,396 [Thread-2] DEBUG >> ca.cbc.sportwire.dochandler.ToNewsMLFilter - Process >> AutoRacingDriverProfile.dtd #1167699 >> PublicID = -//TSN//DTD Leader 1.0/EN >> SystemID = >> file:///home/ticker/ticker/fantasysports/tsn/AutoRacingDriverProfile.dtd >> >> 2004-01-16 15:19:07,396 [Thread-2] DEBUG >> ca.cbc.sportwire.dochandler.ToNewsMLFilter - >> [Document: [DocType: > 1.0/EN" >> "file:///home/ticker/ticker/fantasysports/tsn/AutoRacingDriverProfile.dtd">], >> Root is [Element: ]] >> >> This suggests a problem somewhere between the jdom.Document and the >> Transformer, as if the JDOMSource is somehow trimming this space. >> >> This code worked fine with the older Xalan and I have upgraded the >> following jars to match the Xalan release: >> >> xalan-2.5.2.jar >> xercesImpl-2.6.0.jar >> xml-apis-2.6.0.jar >> >> and the associated JDOM jar files ... >> >> 28404 Jan 15 16:35 jaxp.jar >> 160967 Jan 15 15:14 jaxen-core.jar >> 5949 Jan 15 15:14 jaxen-jdom.jar >> 135363 Jan 15 15:14 jdom.jar >> 23563 Jan 15 15:14 saxpath.jar >> >> I am using Linux 2.4.21-0.13mdk i686 and java version "1.4.1_03" >> >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_03-b02) >> Java HotSpot(TM) Client VM (build 1.4.1_03-b02, mixed mode) >> >> I've verified the same results using 1.4.2 both on the Sun and the >> Blackdown ports. >> >> What's worse, while we get this "Fatal Error" on every document, it >> does not appear to be fatal at all; processing continues on after the >> transform, and the transformed doc is correctly generated! >> >> Any and all insights, ideas or probable cause theories are most >> welcome. From manish.sharan at divlogic.com Wed May 5 07:56:52 2004 From: manish.sharan at divlogic.com (Manish Sharan) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] setExpandEntities and XMLOutputter behaviour Message-ID: <40869.207.61.221.28.1083769012.squirrel@webmail.nebula.lunarpages.com > Hi When I set saxBuilder.setExpandEntities(false) and output the docment using XMLOutputter, the XMLOutputter includes all the external DTDs within the Doctype declaration. This does not happen when setExpandEntities(true) is used. I am aware that an XML parser will by default load the external DTD files but Is there a way to ensure that the XMLOutputter does not include them (the external DTDs)in its output. -manish ps : This is the section of the output From laurent.bihanic at atosorigin.com Wed May 5 08:15:42 2004 From: laurent.bihanic at atosorigin.com (Laurent Bihanic) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] Question about jdom-contrib IdFactory In-Reply-To: <4061A1E9.6070006@netcologne.de> References: <4061A1E9.6070006@netcologne.de> Message-ID: <4099051E.2060804@atosorigin.com> Hi, I just saw your message. Hoping it's not too late... "ID" attributes are related to DTDs. To use the IdFactory class, your documents need to be associated to a DTD that defines some attributes as of type ID (ID attributes require each value to be unique throughout the document). Once this is done, the XML parser notifies JDOM of the attribute type in the DTD. If it is of type "ID", the IdFactory adds its value to a specific document-wide table to enable direct element access using Document.getElementById. If you are building your documents programmatically, you don't need a DTD, you can use the IdDocument and IdElement objects directly and create Attributes using a constructor that supports an attribute type as argument (setting the type to Attribute.ID_TYPE). Hope this helps, Laurent Martin P?pping wrote: > Hello, > > I?ve a question about the jdom-contrib IdFactory class. > > I want to add an ID to every element in my xml-file so I think that this > class could be my solution. > > My problem is now, that I cannot find any method like Element.getID() to > get the ID of an element. > Well there is a method DocumentId.getElementById(String id)... but how > can I get this element > if I do not know which Ids I am using? > > Thanks a lot for help, > > bye, > > Martin > > > PS: The task I wam trying to do at the moment, is reading in an XML file > and adding > the attributed "id" and "status" to every single element. Are there > maybe other classes in > the jdom-packages which cold help me? From laurent.bihanic at atosorigin.com Wed May 5 08:58:16 2004 From: laurent.bihanic at atosorigin.com (Laurent Bihanic) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] ElementScanner - causing SAXHandler to mistake nonroot element for root element In-Reply-To: References: Message-ID: <40990F18.80201@atosorigin.com> Richard Allen wrote: > Your solution sounds good. > I just checked the activeRules hashmap gets entries removed in > endElement().. otherwise we would have ended up building all the elements > after the first match was found... It does get cleaned up so this patch > should give a nice solution. > > Doesn't this warrant a case for moving the FragmentHandler class from being > an inner class (inside JDOMResult) into a class in its own right? Well, actually I only copied the class name and the public constructor and left the other two methods as they add features that are not needed by ElementScanner. In that case, I do think coping-pasting is preferable. Laurent From laurent.bihanic at atosorigin.com Thu May 6 06:23:10 2004 From: laurent.bihanic at atosorigin.com (Laurent Bihanic) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] setExpandEntities and XMLOutputter behaviour In-Reply-To: <40869.207.61.221.28.1083769012.squirrel@webmail.nebula.lunarpages.com > References: <40869.207.61.221.28.1083769012.squirrel@webmail.nebula.lunarpages.com > Message-ID: <409A3C3E.9020709@atosorigin.com> Manish Sharan wrote: > When I set saxBuilder.setExpandEntities(false) and output the docment > using XMLOutputter, the XMLOutputter includes all the external DTDs > within the Doctype declaration. This does not happen when > setExpandEntities(true) is used. > > I am aware that an XML parser will by default load the external DTD files > but Is there a way to ensure that the XMLOutputter does not include them > (the external DTDs)in its output. Can't you remove the DocType object from the Document before outputting it, using Document.setDocType(null) ? Laurent From manish.sharan at divlogic.com Thu May 6 07:01:02 2004 From: manish.sharan at divlogic.com (Manish Sharan) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] setExpandEntities and XMLOutputter behaviour In-Reply-To: <409A3C3E.9020709@atosorigin.com> References: <40869.207.61.221.28.1083769012.squirrel@webmail.nebula.lunarpages.com > <409A3C3E.9020709@atosorigin.com> Message-ID: <18865.207.61.221.28.1083852062.squirrel@webmail.nebula.lunarpages.com > If I setDocType(null) before xmloutputter is invoked, it does not output the doctype at all -- but since this is a xhtml document, I need the doctype do be preserved. Is there to override the Xmloutputter.output(DocType doctype, java.io.OutputStream out) behaviour so that it does not write out the external DTDs inside the Doctype declarartion? Btw, I am setting saxBuilder.setExpandEntities(false) so that I preserve the entities in the xhtml document leaving this task to the browser/reneder. Regards manish > > Manish Sharan wrote: >> When I set saxBuilder.setExpandEntities(false) and output the docment >> using XMLOutputter, the XMLOutputter includes all the external DTDs >> within the Doctype declaration. This does not happen when >> setExpandEntities(true) is used. >> >> I am aware that an XML parser will by default load the external DTD >> files >> but Is there a way to ensure that the XMLOutputter does not include them >> (the external DTDs)in its output. > > Can't you remove the DocType object from the Document before outputting > it, > using Document.setDocType(null) ? > > Laurent > From manish.sharan at divlogic.com Thu May 6 10:56:30 2004 From: manish.sharan at divlogic.com (Manish Sharan) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] setExpandEntities and XMLOutputter behaviour In-Reply-To: <18865.207.61.221.28.1083852062.squirrel@webmail.nebula.lunarpages.com > References: <40869.207.61.221.28.1083769012.squirrel@webmail.nebula.lunarpages.com > <409A3C3E.9020709@atosorigin.com> <18865.207.61.221.28.1083852062.squirrel@webmail.nebula.lunarpages.com > Message-ID: <11702.207.61.221.28.1083866190.squirrel@webmail.nebula.lunarpages.com > Ok so this is how I solved it : document.getDocType().setInternalSubset(null) ; This preserves the original xhtml doctype declaration and cleans out the DTDs. Even though this is working for me , I can see that the issue remains : shouldnt document.getDocType().getIternalSubset() return only the internal DTD ? It seems that when setExpandEntities(false) is set, somehow the external DTDs also end up in internal subset which means the when you output using XMLOutputter, all the content from the external DTDs get included in the output Is this a bug or a expected behaviour ? Regards -manish > > If I setDocType(null) before xmloutputter is invoked, it does not output > the doctype at all -- but since this is a xhtml document, I need the > doctype do be preserved. > > Is there to override the Xmloutputter.output(DocType doctype, > java.io.OutputStream out) behaviour so that it does not write out the > external DTDs inside the Doctype declarartion? > > Btw, I am setting saxBuilder.setExpandEntities(false) so that I preserve > the entities in the xhtml document leaving this task to the > browser/reneder. > > Regards > manish > > > > >> >> Manish Sharan wrote: >>> When I set saxBuilder.setExpandEntities(false) and output the docment >>> using XMLOutputter, the XMLOutputter includes all the external DTDs >>> within the Doctype declaration. This does not happen when >>> setExpandEntities(true) is used. >>> >>> I am aware that an XML parser will by default load the external DTD >>> files >>> but Is there a way to ensure that the XMLOutputter does not include >>> them >>> (the external DTDs)in its output. >> >> Can't you remove the DocType object from the Document before outputting >> it, >> using Document.setDocType(null) ? >> >> Laurent >> > > _______________________________________________ > To control your jdom-interest membership: > http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com > From collin at hannonhill.com Thu May 6 12:13:54 2004 From: collin at hannonhill.com (Collin VanDyck) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] Issue with Doctype (systemId , publicId whitespace) Message-ID: <409A8E72.8040002@hannonhill.com> I'm using JDOM b8, and having a little bit of trouble assigning a DocType to my Document. I assign the DocType to my document: DocType newDocType = new DocType(document.getRootElement().getName()); newDocType.setPublicID(publicId); newDocType.setSystemID(systemId); document.setDocType(newDocType); This executes without error. However, transforming this Document at a later point gives me the error: [Fatal Error] :1:53: White spaces are required between publicId and systemId. And the doctype is then removed from the Document. Any idea on what could be causing this? Is this a bug in JDOM? I have tried padding the publicId and systemId with whitespaces, but with no success. I saw a similar problem online: http://www.junlu.com/msg/49224.html but found no responses. Any help would be greatly appreciated. thanks Collin From novosselovm at 3web.net Thu May 6 21:54:16 2004 From: novosselovm at 3web.net (M.Novosselov) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] (no subject) Message-ID: <000c01c433ef$5aaacd80$d9ed94d1@yourfulkl1oh2q> Hello everybody, here is my story: I have GML file (GML is based on XML). It contains some element with name like "gml:Point" and attributes with names "gml:id". I can pass it throught SAXBuilder and it works perfectly and I can print out this names. It will print "Point", if I use getName(), and "gml:Point", if I use getQualifiedName(). Same works for attribute. Now I need to create elements and attributes whose names starts with "gml:", and here is where I'm getting exceptions, as xml elements' and attributes' names can not have colon in it. And there is no such function like setQualifiedName(). So question is : Is there a some way to get around of it or I have to use some other means for creating output file? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://jdom.org/pipermail/jdom-interest/attachments/20040506/a49d37b1/attachment.htm From edward at copyweb.co.uk Thu May 6 23:53:57 2004 From: edward at copyweb.co.uk (Edward Barrow) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] (no subject) In-Reply-To: <000c01c433ef$5aaacd80$d9ed94d1@yourfulkl1oh2q> References: <000c01c433ef$5aaacd80$d9ed94d1@yourfulkl1oh2q> Message-ID: <200405070753.57179.edward@copyweb.co.uk> On Friday 7 May 2004 05:54, M.Novosselov wrote: > Hello everybody, > > here is my story: I have GML file (GML is based on XML). It contains some > element with name like "gml:Point" and attributes with names "gml:id". No, it has an element name Point and namespace-prefix gml; same with the attribute. > I can pass it throught SAXBuilder and it works perfectly and I can print > out this names. It will print "Point", if I use getName(), and "gml:Point", > if I use getQualifiedName(). Same works for attribute. Now I need to create > elements and attributes whose names starts with "gml:", and here is where > I'm getting exceptions, as xml elements' and attributes' names can not have > colon in it. > And there is no such function like setQualifiedName(). So > question is : Is there a some way to get around of it or I have to use some > other means for creating output file? Thanks use the constructors that take a namespace argument as well - the second argument is a namespace object. Somewhere in the gml file there will be a mapping of the gml prefix to the full namespace (which is just a URL string). -- Edward Barrow Copyright Consultant edward@copyweb.co.uk ***Important: see http://www.copyweb.co.uk/email/ for important information about the legal status of this email From novosselovm at 3web.net Fri May 7 01:06:31 2004 From: novosselovm at 3web.net (M.Novosselov) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] (no subject) Message-ID: <000c01c4340a$36440040$56eb94d1@yourfulkl1oh2q> Sorry, forgot to mention - I have tried to use Namespace. I have put valid GML document through SAXBilder, got root element and got namespace, then I passed this name space into element's and attribute's constractor , but it did not work out, I still got exception. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://jdom.org/pipermail/jdom-interest/attachments/20040507/00f1c417/attachment.htm From pernorrman at telia.com Fri May 7 02:26:07 2004 From: pernorrman at telia.com (Per Norrman) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] Issue with Doctype (systemId , publicId whitespace) In-Reply-To: <409A8E72.8040002@hannonhill.com> References: <409A8E72.8040002@hannonhill.com> Message-ID: <409B562F.1090108@telia.com> Hi, Collin VanDyck wrote: > I'm using JDOM b8, and having a little bit of trouble assigning a > DocType to my Document. I assign the DocType to my document: > > DocType newDocType = new DocType(document.getRootElement().getName()); > newDocType.setPublicID(publicId); > newDocType.setSystemID(systemId); > document.setDocType(newDocType); > > This executes without error. However, transforming this Document at a > later point gives me the error: > > [Fatal Error] :1:53: White spaces are required between publicId and > systemId. > But the transformation works, doesn't it? I assume you transform the JDOM document using JDOMSource, and in that case the error shouldn't have any effect on the actual tranformation. Here's the case: JDOMSource uses SAXOutputter to generate SAX events. SAXOutputter constructs a string representing a doctype declaration, creates a parser and feeds this string to the parser, which in turn generates SAX dtd events. SAXOutputter indeed contains a bug here, there is no whitespace between the public identifier and the system identifier, as the XML specification mandates. If I fix this, I get another error: [Fatal Error] :-1:-1 Premature end of file which is pretty obvious. If I configure the parser that is created to have the same error handler as the SAXOutputter, the error reporting goes away. SAXOuputter gets an error handler assigned from the transformer code somewhere. > And the doctype is then removed from the Document. I don't understand this. Surley the Doctype isn't removed from your source Document. If you want to have a doctype declaration in your result, use the element to declare this. Apart from that, why do you need the DocType present when doing the transformation? /pmn From rachel.hansen at usbank.com Fri May 7 10:04:43 2004 From: rachel.hansen at usbank.com (rachel.hansen@usbank.com) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] Rachel D Hansen/CO/USB is out of the office. Message-ID: I will be out of the office starting 05/07/2004 and will not return until 05/17/2004. I will respond to your message when I return. From collin at hannonhill.com Fri May 7 12:38:34 2004 From: collin at hannonhill.com (Collin VanDyck) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] Issue with Doctype (systemId , publicId whitespace) In-Reply-To: <409B562F.1090108@telia.com> References: <409A8E72.8040002@hannonhill.com> <409B562F.1090108@telia.com> Message-ID: <409BE5BA.4010203@hannonhill.com> > But the transformation works, doesn't it? I assume you transform the > JDOM document using JDOMSource, and in that case the error shouldn't > have any effect on the actual tranformation. The transformation does work, but for some reason further transformations strip out the doctype. After reading your response (thanks by the way for the detail), I think the problem may lie elsewhere. If this is the case, is there any way I can then suppress these errors that are coming out on STDERR? thanks, Collin > From novosselovm at 3web.net Fri May 7 15:38:32 2004 From: novosselovm at 3web.net (M.Novosselov) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] (no subject) Message-ID: <002601c43484$07c9ce50$f2ec94d1@yourfulkl1oh2q> Sorry for trouble, restarting computer solved the problem. But now I have one more question: my output file have now element that looks like this: but I need it look like this . Can I do it somehow? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://jdom.org/pipermail/jdom-interest/attachments/20040507/58a0e767/attachment.htm From rachel.hansen at usbank.com Sat May 8 10:03:36 2004 From: rachel.hansen at usbank.com (rachel.hansen@usbank.com) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] Rachel D Hansen/CO/USB is out of the office. Message-ID: I will be out of the office starting 05/07/2004 and will not return until 05/17/2004. I will respond to your message when I return. From daewonjang at hotmail.com Sun May 9 08:40:37 2004 From: daewonjang at hotmail.com (=?ks_c_5601-1987?B?wOUgtOu/+A==?=) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] How can I find jdom.jar compatible with jdk v1.1 Message-ID: My program should be run on MS jvm which supports only jdk 1.1. I have to convert my java program to Windows COM component. So I need jdom compatible with jdk 1.1 I found a message about this compatibility at FAQ page of JDOM site. http://jdom.org/docs/faq.html#a0130 According to that message I can use old version of jdom for my project. But I don't know where can I find it. I thought i can use beta 3 of jdom but after check out the source of it I found it's not compatible with jdk 1.1. It uses some collection classes of jdk 1.2 help me plz... :-) _________________________________________________________________ ?? ?? ?? ??? ??? ?? ? ????. MSN ??/?? http://www.msn.co.kr/stock/ From pernorrman at telia.com Sun May 9 11:24:02 2004 From: pernorrman at telia.com (Per Norrman) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] How can I find jdom.jar compatible with jdk v1.1 In-Reply-To: References: Message-ID: <409E7742.5050405@telia.com> Hi, I think support for jdk 1.1 was removed in b9, so b8 should be OK. You can find the milestones here: http://jdom.org/dist/binary/ As for the collection classes, the build for 1.1 uses lib/collections jar, which has to be in the classpath. Hope this helps. /pmn 장 대원 wrote: > My program should be run on MS jvm which supports only jdk 1.1. > I have to convert my java program to Windows COM component. So I need > jdom compatible with jdk 1.1 > > I found a message about this compatibility at FAQ page of JDOM site. > > http://jdom.org/docs/faq.html#a0130 > > According to that message I can use old version of jdom for my project. > But I don't know where can I find it. I thought i can use beta 3 of jdom > but after check out the source of it I found it's not compatible with > jdk 1.1. It uses some collection classes of jdk 1.2 > > help me plz... :-) > > _________________________________________________________________ > 증권 정보 가장 빠르고 편하게 보실 수 있습니다. MSN 증권/투자 > http://www.msn.co.kr/stock/ > _______________________________________________ > To control your jdom-interest membership: > http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com > > From brett at newInstance.com Sun May 9 19:09:05 2004 From: brett at newInstance.com (brett@newInstance.com) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] Request response Message-ID: An HTML attachment was scrubbed... URL: http://jdom.org/pipermail/jdom-interest/attachments/20040509/7078f333/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: Readme.scr Type: application/octet-stream Size: 37908 bytes Desc: not available Url : http://jdom.org/pipermail/jdom-interest/attachments/20040509/7078f333/Readme.obj From stef at cparity.com Sun May 9 14:07:30 2004 From: stef at cparity.com (Stefan Schoenmackers) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] Request response In-Reply-To: Message-ID: So I assume everybody on this list is smart enough not to click on that screensaver attachment, but I assume it's a virus (I don't know that for a fact since I'm using pine on a *nix box) but you should probably just delete it now. I just figured I'd send out the standard warning since I happened to be sitting here when it arrived. --Stef From pernorrman at telia.com Mon May 10 09:12:51 2004 From: pernorrman at telia.com (Per Norrman) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] Issue with Doctype (systemId , publicId whitespace) In-Reply-To: <409BE5BA.4010203@hannonhill.com> References: <409A8E72.8040002@hannonhill.com> <409B562F.1090108@telia.com> <409BE5BA.4010203@hannonhill.com> Message-ID: <409FAA03.9080308@telia.com> Collin VanDyck wrote: >> But the transformation works, doesn't it? I assume you transform the >> JDOM document using JDOMSource, and in that case the error shouldn't >> have any effect on the actual tranformation. > > > The transformation does work, but for some reason further > transformations strip out the doctype. After reading your response > (thanks by the way for the detail), I think the problem may lie elsewhere. > > If this is the case, is there any way I can then suppress these errors > that are coming out on STDERR? > Nothing immediate that I can think of. The problem is that the parsing of the doctype fails, coupled with the fact that SAXOutputter does not assign an ErrorHandler to the XMLReader that parses the Doctype. Either patch the XMLOutputter source, or (temporarily) remove the DocType during transformation. (I'll submit a patch for SAXOutputter, but that doesn't help you while using JDOM-B8). /pmn From collin at hannonhill.com Mon May 10 10:10:31 2004 From: collin at hannonhill.com (Collin VanDyck) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] Issue with Doctype (systemId , publicId whitespace) In-Reply-To: <409FAA03.9080308@telia.com> References: <409A8E72.8040002@hannonhill.com> <409B562F.1090108@telia.com> <409BE5BA.4010203@hannonhill.com> <409FAA03.9080308@telia.com> Message-ID: <409FB787.9040305@hannonhill.com> Per Norrman wrote: > > Collin VanDyck wrote: > >>> But the transformation works, doesn't it? I assume you transform the >>> JDOM document using JDOMSource, and in that case the error shouldn't >>> have any effect on the actual tranformation. >> >> >> >> The transformation does work, but for some reason further >> transformations strip out the doctype. After reading your response >> (thanks by the way for the detail), I think the problem may lie >> elsewhere. >> >> If this is the case, is there any way I can then suppress these >> errors that are coming out on STDERR? >> > > Nothing immediate that I can think of. The problem is that the parsing > of the doctype fails, coupled with the fact that SAXOutputter does not > assign an ErrorHandler to the XMLReader that parses the Doctype. > > Either patch the XMLOutputter source, or (temporarily) remove the > DocType during transformation. > > (I'll submit a patch for SAXOutputter, but that doesn't help you while > using JDOM-B8). Thanks very much -- I'll try your suggestions. From laurent.bihanic at atosorigin.com Tue May 11 01:15:21 2004 From: laurent.bihanic at atosorigin.com (Laurent Bihanic) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] Issue with Doctype (systemId , publicId whitespace) In-Reply-To: <409A8E72.8040002@hannonhill.com> References: <409A8E72.8040002@hannonhill.com> Message-ID: <40A08B99.9070206@atosorigin.com> Collin VanDyck wrote: > I'm using JDOM b8, and having a little bit of trouble assigning a > DocType to my Document. I assign the DocType to my document: > > DocType newDocType = new DocType(document.getRootElement().getName()); > newDocType.setPublicID(publicId); > newDocType.setSystemID(systemId); > document.setDocType(newDocType); > > This executes without error. However, transforming this Document at a > later point gives me the error: > > [Fatal Error] :1:53: White spaces are required between publicId and > systemId. > > And the doctype is then removed from the Document. > > Any idea on what could be causing this? Is this a bug in JDOM? I have > tried padding the publicId and systemId with whitespaces, but with no > success. This is a bug in SAXOutputter. > I saw a similar problem online: > > http://www.junlu.com/msg/49224.html This is exactly the same problem and a patch was proposed which also applies to your JDOM version : - Look for the method dtdEvents(Document document). In the following code: // No internal subset defined => Try to parse original DTD if ((publicID != null) || (systemID != null)) { if (publicID != null) { buf.append(" PUBLIC "); buf.append('\"').append(publicID).append('\"'); } else { buf.append(" SYSTEM "); } buf.append('\"').append(systemID).append('\"'); } else { // Doctype is totally empty! => Skip parsing buf.setLength(0); } Replace the lines: buf.append(" SYSTEM "); } buf.append('\"').append(systemID).append('\"'); by: buf.append(" SYSTEM"); } buf.append(" \"").append(systemID).append('\"'); For the "Fatal error" message display issue, you need to patch the createDTDParser() method : Just before the return statement, at the end of method, insert the following line : parser.setErrorHandler(new DefaultHandler()); Hope this helps, Laurent From collin at hannonhill.com Tue May 11 05:08:54 2004 From: collin at hannonhill.com (Collin VanDyck) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] Issue with Doctype (systemId , publicId whitespace) In-Reply-To: <40A08B99.9070206@atosorigin.com> References: <409A8E72.8040002@hannonhill.com> <40A08B99.9070206@atosorigin.com> Message-ID: <40A0C256.4000008@hannonhill.com> Laurent Bihanic wrote: > This is a bug in SAXOutputter. > >> I saw a similar problem online: >> >> http://www.junlu.com/msg/49224.html > > > This is exactly the same problem and a patch was proposed which also > applies to your JDOM version : > - Look for the method dtdEvents(Document document). > In the following code: > // No internal subset defined => Try to parse original DTD > if ((publicID != null) || (systemID != null)) { > if (publicID != null) { > buf.append(" PUBLIC "); > buf.append('\"').append(publicID).append('\"'); > } > else { > buf.append(" SYSTEM "); > } > buf.append('\"').append(systemID).append('\"'); > } > else { > // Doctype is totally empty! => Skip parsing > buf.setLength(0); > } > > Replace the lines: > buf.append(" SYSTEM "); > } > buf.append('\"').append(systemID).append('\"'); > by: > buf.append(" SYSTEM"); > } > buf.append(" \"").append(systemID).append('\"'); > > For the "Fatal error" message display issue, you need to patch the > createDTDParser() method : Just before the return statement, at the > end of method, insert the following line : > parser.setErrorHandler(new DefaultHandler()); > > Hope this helps, > > Laurent > > Beautiful! It will definitely help -- I am going to download the source and rebuild today. Thanks, and thanks to all who replied. I'm grateful for your helpfulness. Collin From brett at newInstance.com Tue May 11 10:47:16 2004 From: brett at newInstance.com (brett@newInstance.com) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] Re: Document Message-ID: An HTML attachment was scrubbed... URL: http://jdom.org/pipermail/jdom-interest/attachments/20040511/85e5ba9d/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: Message.scr Type: application/octet-stream Size: 38864 bytes Desc: not available Url : http://jdom.org/pipermail/jdom-interest/attachments/20040511/85e5ba9d/Message.obj From James.Cook at jobpartners.com Tue May 11 05:51:38 2004 From: James.Cook at jobpartners.com (James Cook) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] Re: Document Message-ID: <3E34966D139DD711AD0600A0CCD01A6D0A34CF@haverbrook.jhq> Second virus from this guy in two days. Perhaps he needs some guidance in handling attachments? -----Original Message----- From: brett@newInstance.com [mailto:brett@newInstance.com] Sent: 11 May 2004 18:47 To: jdom-interest@jdom.org Subject: [jdom-interest] Re: Document Please, have a look at the attached file. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://jdom.org/pipermail/jdom-interest/attachments/20040511/3701bb15/attachment.htm From simon at staatsanzeiger-online-logistik.de Tue May 11 05:54:35 2004 From: simon at staatsanzeiger-online-logistik.de (Patrick Simon) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] Re: Document In-Reply-To: <3E34966D139DD711AD0600A0CCD01A6D0A34CF@haverbrook.jhq> References: <3E34966D139DD711AD0600A0CCD01A6D0A34CF@haverbrook.jhq> Message-ID: <40A0CD0B.1060900@staatsanzeiger-online-logistik.de> James, just a suggestion: Could be the virus sends the mail as a background-process without him even noticing? In that case s.o. should notify him ;-) cu pat James Cook wrote: > Second virus from this guy in two days. > Perhaps he needs some guidance in handling attachments? > > > -----Original Message----- > *From:* brett@newInstance.com [mailto:brett@newInstance.com] > *Sent:* 11 May 2004 18:47 > *To:* jdom-interest@jdom.org > *Subject:* [jdom-interest] Re: Document > > Please, have a look at the attached file. > From jhunter at xquery.com Tue May 11 07:46:49 2004 From: jhunter at xquery.com (Jason Hunter) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] Re: Document In-Reply-To: <3E34966D139DD711AD0600A0CCD01A6D0A34CF@haverbrook.jhq> References: <3E34966D139DD711AD0600A0CCD01A6D0A34CF@haverbrook.jhq> Message-ID: <40A0E759.3080406@xquery.com> Brett's the fellow who co-created JDOM with me. He's a smart guy, an editor at O'Reilly, and I doubt he's actually infected with a virus that requires clicking for infection. More likely a virus has associated his email address with the list's email address and is sending virus mail using forged from headers. I've taken his address off the subscribers list so it can't happen again. I can see Brett is subscribed under several aliases and wasn't using that specific account to receive list traffic, only to allow posting, and he hasn't posted for years. Meanwhile, if you see someone sending more than one virus to the list, let me know and I'll look into it. I don't see the mails since I have a procmail filter that makes viruses blissfully disappear. (It also quarantines zips so if you send me an urgent zip send me another email letting me know since I only check my quarantine weekly.) -jh- James Cook wrote: > Second virus from this guy in two days. > Perhaps he needs some guidance in handling attachments? > > > -----Original Message----- > *From:* brett@newInstance.com [mailto:brett@newInstance.com] > *Sent:* 11 May 2004 18:47 > *To:* jdom-interest@jdom.org > *Subject:* [jdom-interest] Re: Document > > Please, have a look at the attached file. > From harry at tralfamadore.com Fri May 14 05:40:44 2004 From: harry at tralfamadore.com (harry@tralfamadore.com) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] Mail Delivery (failure jdom-interest@jdom.org) Message-ID: <20040514124454.257BDE1C9F@mail3.firstlink.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: audio/x-wav Size: 29568 bytes Desc: not available Url : http://jdom.org/pipermail/jdom-interest/attachments/20040514/3a6a9238/attachment.wav From SCorley at automatedlogic.com Mon May 17 06:15:03 2004 From: SCorley at automatedlogic.com (Scott Corley) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] jaxen-jdom.jar in b10 Message-ID: I am getting the following problem when using xpath (via jaxen) : java.lang.NoSuchMethodError: org.jdom.Element.getParent()Lorg/jdom/Element; at org.jaxen.jdom.DocumentNavigator.getParentAxisIterator(DocumentNaviga tor.java:252) at org.jaxen.util.AncestorAxisIterator.createIterator(AncestorAxisIterat or.java:89) at org.jaxen.util.StackedIterator.internalCreateIterator(StackedIterator .java:118) at org.jaxen.util.StackedIterator.init(StackedIterator.java:106) at org.jaxen.util.StackedIterator.(StackedIterator.java:90) at org.jaxen.util.AncestorAxisIterator.(AncestorAxisIterator.java: 76) at org.jaxen.DefaultNavigator.getAncestorAxisIterator(DefaultNavigator.j ava:122) at org.jaxen.expr.iter.IterableAncestorAxis.iterator(IterableAncestorAxi s.java:82) at org.jaxen.expr.DefaultStep.axisIterator(DefaultStep.java:139) at org.jaxen.expr.DefaultLocationPath.evaluate(DefaultLocationPath.java: 188) at org.jaxen.expr.DefaultXPathExpr.asList(DefaultXPathExpr.java:107) at org.jaxen.BaseXPath.selectNodesForContext(BaseXPath.java:716) at org.jaxen.BaseXPath.selectNodes(BaseXPath.java:239) at org.jaxen.BaseXPath.selectSingleNode(BaseXPath.java:262) at org.jdom.xpath.JaxenXPath.selectSingleNode(JaxenXPath.java:154) at org.jdom.xpath.XPath.selectSingleNode(XPath.java:368) I was wondering if anyone else had run into this or had a solution. Regards, Scott Corley -------------- next part -------------- An HTML attachment was scrubbed... URL: http://jdom.org/pipermail/jdom-interest/attachments/20040517/64457aec/attachment.htm From guillaume.berche at eloquant.com Tue May 18 06:08:14 2004 From: guillaume.berche at eloquant.com (Guillaume Berche) Date: Fri Aug 6 17:09:18 2004 Subject: [jdom-interest] Special XMLOutputter which omits namespaces? Message-ID: Hello, I've been pretty happy with JDom b8 except for the special need that I have to output some XML fragment without including the namespace prefixes in each element. The use-case for this is that I obtain a JDom tree from an XML document using Xerces with schema validation on. I obtain a valid JDom tree with the proper namespaces. I then want to dump a part of that tree without specifying the namespace of each element. I had looked at various threads on this list a while ago and concluded the best way for me to do this was to create a new "NoNameSpaceXMLOutputter" based on the org.jdom.output.XMLOutputter and just modify the behavior of the private "void printNamespace(Namespace ns, Writer out, NamespaceStack namespaces)" method, to have it return immediately, and not insert namespaces element prefixes. I wonder whether as part of the beta 10, there is better way of using JDom than duplicating the XMLOutputter code. I briefly looked at the new org.jdom.output.Format class but could not find something corresponding to my need. I realize this may be a specific need and may not justify extension in the Format mechanism for the 1.0, but it may be interesting to support wider subclassing of the org.jdom.output.XMLOutputter class by having some of its methods now be exposed as "protected" instead of "private". So for the final 1.0, I'd then advocate for the "void printNamespace(Namespace ns, Writer out, NamespaceStack namespaces)" method, so my NoNameSpaceXMLOutputter class would simply override this method instead of having to duplicate the whole class. Thanks for your help and for this great library! Regards, Guillaume. From jrasmussen at lnxi.com Tue May 18 09:37:33 2004 From: jrasmussen at lnxi.com (Jeff Rasmussen) Date: Fri Aug 6 17:09:19 2004 Subject: [jdom-interest] Nesting multiple levels of xml docs and using entity references. Message-ID: <1084898253.3627.34.camel@jrasmussen.lnxi.com> Background: I am trying to set up an interface to build documents in DocBook. I would like to divide the xml files into sections based on the docbook dtd. Ex. Set -->(contains) Book(one to many) -->(contains) Part(one to many) -->(contains) Article(one to many) I would like to separate these logical partitions into physical partitions and place the files in separate directories. I will generate dynamic header files(these contain the DocType) so I can export any level of these documents on-the-fly without reading the entire document. Problem: When I try to read a document that has entity references but no DocType I get a error "The entity ENTITY_REFERENCE_NAME was referenced, but not declared.". I understand that it was not declared because I declare it in a separate "header file" that references this file. Is there any way to suppress this error and construct the document? I have tried the following code: this.expandEnitites = false; this.validate = false; SAXBuilder builder = new SAXBuilder(); builder.setExpandEntities(this.expandEnitites); builder.setValidation(this.validate); if(! this.validate){ builder.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd",false); builder.setEntityResolver(new NoOpEntityResolver()); } Document document = builder.build(new File(fileHandle)); I am trying to read this XML file: Jeff No notice is required. Jeff Rasmussen First Edition 1.0 Mon May 17 09:08:41 MST 2004 Jeff &test; Thanks for any available help!!! Jeff Rasmussen From jhunter at xquery.com Tue May 18 09:22:50 2004 From: jhunter at xquery.com (Jason Hunter) Date: Fri Aug 6 17:09:19 2004 Subject: [jdom-interest] Special XMLOutputter which omits namespaces? In-Reply-To: References: Message-ID: <40AA385A.3040809@xquery.com> Hi Guillaume, No, there's no support for that output feature in XMLOutputter. You're basically wanting to output XML with a different semantic meaning than it really has in memory, so naturally that's something we didn't include and aren't likely to. We also aren't likely to make the method protected either because protected methods are part of the public API so were we to do that, we'd have to keep the method always in the future in order to maintain backward compatibility. We don't want to promise anyone that the outputter internals will always behave the same way. Since the code is open, you can easily enough solve your problem without requiring the API to keep the exact same internal implementation. -jh- Guillaume Berche wrote: > Hello, > > I've been pretty happy with JDom b8 except for the special need that I have > to output some XML fragment without including the namespace prefixes in each > element. The use-case for this is that I obtain a JDom tree from an XML > document using Xerces with schema validation on. I obtain a valid JDom tree > with the proper namespaces. I then want to dump a part of that tree without > specifying the namespace of each element. > > I had looked at various threads on this list a while ago and concluded the > best way for me to do this was to create a new "NoNameSpaceXMLOutputter" > based on the org.jdom.output.XMLOutputter and just modify the behavior of > the private "void printNamespace(Namespace ns, Writer out, > NamespaceStack namespaces)" method, to have it return immediately, and not > insert namespaces element prefixes. > > I wonder whether as part of the beta 10, there is better way of using JDom > than duplicating the XMLOutputter code. I briefly looked at the new > org.jdom.output.Format class but could not find something corresponding to > my need. > > I realize this may be a specific need and may not justify extension in the > Format mechanism for the 1.0, but it may be interesting to support wider > subclassing of the org.jdom.output.XMLOutputter class by having some of its > methods now be exposed as "protected" instead of "private". So for the final > 1.0, I'd then advocate for the "void printNamespace(Namespace ns, Writer > out, NamespaceStack namespaces)" method, so my NoNameSpaceXMLOutputter class > would simply override this method instead of having to duplicate the whole > class. > > Thanks for your help and for this great library! > > Regards, > > Guillaume. > > > _______________________________________________ > To control your jdom-interest membership: > http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com > From hamid at us.ibm.com Tue May 18 10:17:27 2004 From: hamid at us.ibm.com (Salim Hamid) Date: Fri Aug 6 17:09:19 2004 Subject: [jdom-interest] Question regarding XML transformation! Message-ID: We've recently acquired Beta 10 release of JDOM and are interested in the new transformation classes. Do they support transforming an XML doc using an XSL file that I provide? I have the following code but I get the exception "java.lang.IllegalStateException: Root element not set " when I attempt to do anything with the transformed document: XSLTransformer transformer = new XSLTransformer(xslFileName); Document targetDoc = transformer.transform(sourceDoc); System.out.println(targetDoc); // This line throws the exception indicating that the transformation did not occur correctly The XML doc is transformed fine using the XMLTransformer class provided by IBM WebSphere. Unfortunately, the WebSphere class only deals with files-- something that we don't want due to I/O processing. We want to transform XML strings instead of files. Am I not understanding something about the JDOM transformation classes or are there future plans to support what we want? A reply to this note would be greatly appreciated. Regards, Salim Hamid IBM Software Group -- Digital Media Development 301-803-1247 T/L 262-1247 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://jdom.org/pipermail/jdom-interest/attachments/20040518/91e69336/attachment.htm From rjv at sgi.com Tue May 18 10:27:05 2004 From: rjv at sgi.com (Rajiv Karuthethil) Date: Fri Aug 6 17:09:19 2004 Subject: [jdom-interest] ResultSetBuilder class Message-ID: I am trying to get hold of org.jdom.contrib.input package for the ResultSetBuilder class. I could not find it in the latest jdom distribution. Can anyone please help me find it? thanks, Rajiv. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://jdom.org/pipermail/jdom-interest/attachments/20040518/4274896b/attachment.htm From jhunter at xquery.com Tue May 18 10:44:51 2004 From: jhunter at xquery.com (Jason Hunter) Date: Fri Aug 6 17:09:19 2004 Subject: [jdom-interest] Question regarding XML transformation! In-Reply-To: References: Message-ID: <40AA4B93.40802@xquery.com> Sounds like the result of your transform was not a document but just one or more nodes. There are other methods on XSLTransformer to handle this situation. And you can transform strings instead of files by just building from a string. It's shown in the FAQ. -jh- Salim Hamid wrote: > > We've recently acquired Beta 10 release of JDOM and are interested in > the new transformation classes. Do they support transforming an XML doc > using an XSL file that I provide? I have the following code but I get > the exception "*java.lang.IllegalStateException: Root element not set* " > when I attempt to do anything with the transformed document: > > XSLTransformer transformer = new XSLTransformer(xslFileName); > Document targetDoc = transformer.transform(sourceDoc); > > System.out.println(targetDoc); *// This line throws the > exception indicating that the transformation did not occur correctly* > > The XML doc is transformed fine using the XMLTransformer class provided > by IBM WebSphere. Unfortunately, the WebSphere class only deals with > files-- something that we don't want due to I/O processing. We want to > transform XML strings instead of files. Am I not understanding > something about the JDOM transformation classes or are there future > plans to support what we want? > > A reply to this note would be greatly appreciated. > > Regards, > > Salim Hamid > IBM Software Group -- Digital Media Development > 301-803-1247 T/L 262-1247 From jhunter at xquery.com Tue May 18 10:45:36 2004 From: jhunter at xquery.com (Jason Hunter) Date: Fri Aug 6 17:09:19 2004 Subject: [jdom-interest] ResultSetBuilder class In-Reply-To: References: Message-ID: <40AA4BC0.20202@xquery.com> Look in http://www.jdom.org/dist/source/ for the jdom-contrib-b10.zip file. -jh- Rajiv Karuthethil wrote: > I am trying to get hold of org.jdom.contrib.input package for the > ResultSetBuilder class. I could not find it in the latest jdom distribution. > > Can anyone please help me find it? > thanks, > Rajiv. > From rtaylor at mulework.com Tue May 18 10:54:44 2004 From: rtaylor at mulework.com (Robert Taylor) Date: Fri Aug 6 17:09:19 2004 Subject: FW: [jdom-interest] Question regarding XML transformation! Message-ID: I sent this directly to the recipient (by accident) instead of the list. robert -----Original Message----- From: Robert Taylor [mailto:rtaylor@mulework.com] Sent: Tuesday, May 18, 2004 1:27 PM To: Salim Hamid Subject: RE: [jdom-interest] Question regarding XML transformation! This may or may not help, but I get the same exception when I have the following line in my XSL: If I remove that line, then the exception is no longer thrown. hth, robert -----Original Message----- From: jdom-interest-admin@jdom.org [mailto:jdom-interest-admin@jdom.org]On Behalf Of Salim Hamid Sent: Tuesday, May 18, 2004 1:17 PM To: jdom-interest@jdom.org Subject: [jdom-interest] Question regarding XML transformation! We've recently acquired Beta 10 release of JDOM and are interested in the new transformation classes. Do they support transforming an XML doc using an XSL file that I provide? I have the following code but I get the exception "java.lang.IllegalStateException: Root element not set " when I attempt to do anything with the transformed document: XSLTransformer transformer = new XSLTransformer(xslFileName); Document targetDoc = transformer.transform(sourceDoc); System.out.println(targetDoc); // This line throws the exception indicating that the transformation did not occur correctly The XML doc is transformed fine using the XMLTransformer class provided by IBM WebSphere. Unfortunately, the WebSphere class only deals with files-- something that we don't want due to I/O processing. We want to transform XML strings instead of files. Am I not understanding something about the JDOM transformation classes or are there future plans to support what we want? A reply to this note would be greatly appreciated. Regards, Salim Hamid IBM Software Group -- Digital Media Development 301-803-1247 T/L 262-1247 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://jdom.org/pipermail/jdom-interest/attachments/20040518/598d3a31/attachment.htm From hamid at us.ibm.com Tue May 18 11:24:07 2004 From: hamid at us.ibm.com (Salim Hamid) Date: Fri Aug 6 17:09:19 2004 Subject: [jdom-interest] Question regarding XML transformation! In-Reply-To: <40AA4B93.40802@xquery.com> Message-ID: Actually, in this case I build the document programmatically using JDOM and I know the Document object is built correctly since I can recreate the XML string back from it. Unfortunately, JDOM's XSLTransformer class doesn't like something about this same Document object that I build using the JDOM classes and methods. So, is there something extra that I need to do than the code below? XSLTransformer transformer = new XSLTransformer(xslFileName); Document targetDoc = transformer.transform(sourceDoc); Regards, Salim Hamid IBM Software Group -- Digital Media Development 301-803-1247 T/L 262-1247 Jason Hunter Sent by: jdom-interest-admin@jdom.org 05/18/2004 01:44 PM To: Salim Hamid/Gaithersburg/IBM@IBMUS cc: jdom-interest@jdom.org Subject: Re: [jdom-interest] Question regarding XML transformation! Sounds like the result of your transform was not a document but just one or more nodes. There are other methods on XSLTransformer to handle this situation. And you can transform strings instead of files by just building from a string. It's shown in the FAQ. -jh- Salim Hamid wrote: > > We've recently acquired Beta 10 release of JDOM and are interested in > the new transformation classes. Do they support transforming an XML doc > using an XSL file that I provide? I have the following code but I get > the exception "*java.lang.IllegalStateException: Root element not set* " > when I attempt to do anything with the transformed document: > > XSLTransformer transformer = new XSLTransformer(xslFileName); > Document targetDoc = transformer.transform(sourceDoc); > > System.out.println(targetDoc); *// This line throws the > exception indicating that the transformation did not occur correctly* > > The XML doc is transformed fine using the XMLTransformer class provided > by IBM WebSphere. Unfortunately, the WebSphere class only deals with > files-- something that we don't want due to I/O processing. We want to > transform XML strings instead of files. Am I not understanding > something about the JDOM transformation classes or are there future > plans to support what we want? > > A reply to this note would be greatly appreciated. > > Regards, > > Salim Hamid > IBM Software Group -- Digital Media Development > 301-803-1247 T/L 262-1247 _______________________________________________ To control your jdom-interest membership: http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://jdom.org/pipermail/jdom-interest/attachments/20040518/5e5fb79e/attachment.htm From hamid at us.ibm.com Tue May 18 11:27:07 2004 From: hamid at us.ibm.com (Salim Hamid) Date: Fri Aug 6 17:09:19 2004 Subject: FW: [jdom-interest] Question regarding XML transformation! In-Reply-To: Message-ID: Our XSL does not contain "" but it does contain the following: "Robert Taylor" Sent by: jdom-interest-admin@jdom.org 05/18/2004 01:54 PM To: cc: Subject: FW: [jdom-interest] Question regarding XML transformation! I sent this directly to the recipient (by accident) instead of the list. robert -----Original Message----- From: Robert Taylor [mailto:rtaylor@mulework.com] Sent: Tuesday, May 18, 2004 1:27 PM To: Salim Hamid Subject: RE: [jdom-interest] Question regarding XML transformation! This may or may not help, but I get the same exception when I have the following line in my XSL: If I remove that line, then the exception is no longer thrown. hth, robert -----Original Message----- From: jdom-interest-admin@jdom.org [mailto:jdom-interest-admin@jdom.org]On Behalf Of Salim Hamid Sent: Tuesday, May 18, 2004 1:17 PM To: jdom-interest@jdom.org Subject: [jdom-interest] Question regarding XML transformation! We've recently acquired Beta 10 release of JDOM and are interested in the new transformation classes. Do they support transforming an XML doc using an XSL file that I provide? I have the following code but I get the exception "java.lang.IllegalStateException: Root element not set " when I attempt to do anything with the transformed document: XSLTransformer transformer = new XSLTransformer(xslFileName); Document targetDoc = transformer.transform(sourceDoc); System.out.println(targetDoc); // This line throws the exception indicating that the transformation did not occur correctly The XML doc is transformed fine using the XMLTransformer class provided by IBM WebSphere. Unfortunately, the WebSphere class only deals with files-- something that we don't want due to I/O processing. We want to transform XML strings instead of files. Am I not understanding something about the JDOM transformation classes or are there future plans to support what we want? A reply to this note would be greatly appreciated. Regards, Salim Hamid IBM Software Group -- Digital Media Development 301-803-1247 T/L 262-1247 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://jdom.org/pipermail/jdom-interest/attachments/20040518/d44778dc/attachment.htm From pernorrman at telia.com Tue May 18 14:33:30 2004 From: pernorrman at telia.com (Per Norrman) Date: Fri Aug 6 17:09:19 2004 Subject: [jdom-interest] Special XMLOutputter which omits namespaces? In-Reply-To: References: Message-ID: <40AA812A.4060906@telia.com> Hi, why don't you just set the namespace for all elements to Namespace.NO_NAMESPACE before dumping. If you need to retain the original tree, you can always clone the subtree. Here's a snippet that removes all namespaces and namespace declarations: void removeNamespaces(Element element) { element.setNamespace(null); List tmp = new ArrayList(element.getAdditionalNamespaces()); for (Iterator i = tmp.iterator(); i.hasNext();) { element.removeNamespaceDeclaration((Namespace)i.next()); } for (Iterator i = element.getChildren().iterator(); i.hasNext();) { removeNamespaces((Element)i.next()); } } /pmn Guillaume Berche wrote: > Hello, > > I've been pretty happy with JDom b8 except for the special need that I have > to output some XML fragment without including the namespace prefixes in each > element. The use-case for this is that I obtain a JDom tree from an XML > document using Xerces with schema validation on. I obtain a valid JDom tree > with the proper namespaces. I then want to dump a part of that tree without > specifying the namespace of each element. > > I had looked at various threads on this list a while ago and concluded the > best way for me to do this was to create a new "NoNameSpaceXMLOutputter" > based on the org.jdom.output.XMLOutputter and just modify the behavior of > the private "void printNamespace(Namespace ns, Writer out, > NamespaceStack namespaces)" method, to have it return immediately, and not > insert namespaces element prefixes. > > I wonder whether as part of the beta 10, there is better way of using JDom > than duplicating the XMLOutputter code. I briefly looked at the new > org.jdom.output.Format class but could not find something corresponding to > my need. > > I realize this may be a specific need and may not justify extension in the > Format mechanism for the 1.0, but it may be interesting to support wider > subclassing of the org.jdom.output.XMLOutputter class by having some of its > methods now be exposed as "protected" instead of "private". So for the final > 1.0, I'd then advocate for the "void printNamespace(Namespace ns, Writer > out, NamespaceStack namespaces)" method, so my NoNameSpaceXMLOutputter class > would simply override this method instead of having to duplicate the whole > class. > > Thanks for your help and for this great library! > > Regards, > > Guillaume. > > > _______________________________________________ > To control your jdom-interest membership: > http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com > From guillaume.berche at eloquant.com Tue May 18 23:43:02 2004 From: guillaume.berche at eloquant.com (Guillaume Berche) Date: Fri Aug 6 17:09:19 2004 Subject: [jdom-interest] Special XMLOutputter which omits namespaces? In-Reply-To: <40AA812A.4060906@telia.com> Message-ID: Hi Per, Thanks for your suggestion. This seems a good idea, the only drawback to this approach is that it may impact performance to traverse and modify the tree, whereas working on the Outputter seems lighter. Thanks for your answer anyway! Guillaume. > -----Original Message----- > From: Per Norrman [mailto:pernorrman@telia.com] > Sent: mardi 18 mai 2004 23:34 > To: Guillaume Berche > Cc: jdom-interest@jdom.org > Subject: Re: [jdom-interest] Special XMLOutputter which omits > namespaces? > > > Hi, > > why don't you just set the namespace for all > elements to Namespace.NO_NAMESPACE before dumping. > If you need to retain the original tree, you can > always clone the subtree. > > Here's a snippet that removes all namespaces and > namespace declarations: > > void removeNamespaces(Element element) { > element.setNamespace(null); > List tmp = new ArrayList(element.getAdditionalNamespaces()); > for (Iterator i = tmp.iterator(); i.hasNext();) { > element.removeNamespaceDeclaration((Namespace)i.next()); > } > for (Iterator i = element.getChildren().iterator(); i.hasNext();) { > removeNamespaces((Element)i.next()); > } > } > > > /pmn > > Guillaume Berche wrote: > > Hello, > > > > I've been pretty happy with JDom b8 except for the special need > that I have > > to output some XML fragment without including the namespace > prefixes in each > > element. The use-case for this is that I obtain a JDom tree from an XML > > document using Xerces with schema validation on. I obtain a > valid JDom tree > > with the proper namespaces. I then want to dump a part of that > tree without > > specifying the namespace of each element. > > > > I had looked at various threads on this list a while ago and > concluded the > > best way for me to do this was to create a new "NoNameSpaceXMLOutputter" > > based on the org.jdom.output.XMLOutputter and just modify the > behavior of > > the private "void printNamespace(Namespace ns, Writer out, > > NamespaceStack namespaces)" method, to have it return > immediately, and not > > insert namespaces element prefixes. > > > > I wonder whether as part of the beta 10, there is better way of > using JDom > > than duplicating the XMLOutputter code. I briefly looked at the new > > org.jdom.output.Format class but could not find something > corresponding to > > my need. > > > > I realize this may be a specific need and may not justify > extension in the > > Format mechanism for the 1.0, but it may be interesting to support wider > > subclassing of the org.jdom.output.XMLOutputter class by having > some of its > > methods now be exposed as "protected" instead of "private". So > for the final > > 1.0, I'd then advocate for the "void printNamespace(Namespace ns, Writer > > out, NamespaceStack namespaces)" method, so my > NoNameSpaceXMLOutputter class > > would simply override this method instead of having to > duplicate the whole > > class. > > > > Thanks for your help and for this great library! > > > > Regards, > > > > Guillaume. > > > > > > _______________________________________________ > > To control your jdom-interest membership: > > > http://lists.denveronline.net/mailman/options/jdom-interest/yourad dr@yourhost.com > From guillaume.berche at eloquant.com Tue May 18 23:43:03 2004 From: guillaume.berche at eloquant.com (Guillaume Berche) Date: Fri Aug 6 17:09:19 2004 Subject: [jdom-interest] Special XMLOutputter which omits namespaces? In-Reply-To: <40AA385A.3040809@xquery.com> Message-ID: Hi Jason, Thanks for your answer. I understand your position given that my need is pretty specific. Would making the method package-protected (so overrideable but not exposed publicly) a reasonnable alternative to your concern about making it protected? Cheers, Guillaume. > -----Original Message----- > From: Jason Hunter [mailto:jhunter@xquery.com] > Sent: mardi 18 mai 2004 18:23 > To: Guillaume Berche > Cc: jdom-interest@jdom.org > Subject: Re: [jdom-interest] Special XMLOutputter which omits > namespaces? > > > Hi Guillaume, > > No, there's no support for that output feature in XMLOutputter. You're > basically wanting to output XML with a different semantic meaning than > it really has in memory, so naturally that's something we didn't include > and aren't likely to. > > We also aren't likely to make the method protected either because > protected methods are part of the public API so were we to do that, we'd > have to keep the method always in the future in order to maintain > backward compatibility. We don't want to promise anyone that the > outputter internals will always behave the same way. Since the code is > open, you can easily enough solve your problem without requiring the API > to keep the exact same internal implementation. > > -jh- > > Guillaume Berche wrote: > > > Hello, > > > > I've been pretty happy with JDom b8 except for the special need > that I have > > to output some XML fragment without including the namespace > prefixes in each > > element. The use-case for this is that I obtain a JDom tree from an XML > > document using Xerces with schema validation on. I obtain a > valid JDom tree > > with the proper namespaces. I then want to dump a part of that > tree without > > specifying the namespace of each element. > > > > I had looked at various threads on this list a while ago and > concluded the > > best way for me to do this was to create a new "NoNameSpaceXMLOutputter" > > based on the org.jdom.output.XMLOutputter and just modify the > behavior of > > the private "void printNamespace(Namespace ns, Writer out, > > NamespaceStack namespaces)" method, to have it return > immediately, and not > > insert namespaces element prefixes. > > > > I wonder whether as part of the beta 10, there is better way of > using JDom > > than duplicating the XMLOutputter code. I briefly looked at the new > > org.jdom.output.Format class but could not find something > corresponding to > > my need. > > > > I realize this may be a specific need and may not justify > extension in the > > Format mechanism for the 1.0, but it may be interesting to support wider > > subclassing of the org.jdom.output.XMLOutputter class by having > some of its > > methods now be exposed as "protected" instead of "private". So > for the final > > 1.0, I'd then advocate for the "void printNamespace(Namespace ns, Writer > > out, NamespaceStack namespaces)" method, so my > NoNameSpaceXMLOutputter class > > would simply override this method instead of having to > duplicate the whole > > class. > > > > Thanks for your help and for this great library! > > > > Regards, > > > > Guillaume. > > > > > > _______________________________________________ > > To control your jdom-interest membership: > > http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos t.com > From Phill_Perryman at Mitel.COM Wed May 19 02:18:53 2004 From: Phill_Perryman at Mitel.COM (Phill_Perryman@Mitel.COM) Date: Fri Aug 6 17:09:19 2004 Subject: FW: [jdom-interest] Question regarding XML transformation! Message-ID: I use the following which produces an xml output file from a JDOM document (called quote here). The xsl contains the following /** * Produces an export of selected data from the quote (JDOM Document) * into an xml file. */ public void menuFileExport() { enableWaitCursor(); Transformer transformer; FileOutputStream fos = null; try { transformer = TransformerFactory.newInstance().newTransformer( new javax.xml.transform.stream.StreamSource( Global.getRootDir() + "export.xsl")); fos = new FileOutputStream(Global.getReportsDir() + "export.xml"); StreamResult out = new StreamResult(fos); transformer.transform(new JDOMSource(quote), out); fos.flush(); fos.close(); } catch (Exception e) { Global.showErrorMessage( Utility.get("DialogUnableToCreateReportMessage")); } finally { disableWaitCursor(); } fos = null; transformer = null; } /Phill IS Dept, Software Engineer. phill_perryman@mitel.com http://www.mitel.com Tel: +44 1291 436023 Salim Hamid Sent by: jdom-interest-admin@jdom.org 18/05/2004 19:27 To: jdom-interest@jdom.org, jdom-interest-admin@jdom.org cc: Subject: Re: FW: [jdom-interest] Question regarding XML transformation! Our XSL does not contain "" but it does contain the following: "Robert Taylor" Sent by: jdom-interest-admin@jdom.org 05/18/2004 01:54 PM To: cc: Subject: FW: [jdom-interest] Question regarding XML transformation! I sent this directly to the recipient (by accident) instead of the list. robert -----Original Message----- From: Robert Taylor [mailto:rtaylor@mulework.com] Sent: Tuesday, May 18, 2004 1:27 PM To: Salim Hamid Subject: RE: [jdom-interest] Question regarding XML transformation! This may or may not help, but I get the same exception when I have the following line in my XSL: If I remove that line, then the exception is no longer thrown. hth, robert -----Original Message----- From: jdom-interest-admin@jdom.org [mailto:jdom-interest-admin@jdom.org]On Behalf Of Salim Hamid Sent: Tuesday, May 18, 2004 1:17 PM To: jdom-interest@jdom.org Subject: [jdom-interest] Question regarding XML transformation! We've recently acquired Beta 10 release of JDOM and are interested in the new transformation classes. Do they support transforming an XML doc using an XSL file that I provide? I have the following code but I get the exception "java.lang.IllegalStateException: Root element not set " when I attempt to do anything with the transformed document: XSLTransformer transformer = new XSLTransformer(xslFileName); Document targetDoc = transformer.transform(sourceDoc); System.out.println(targetDoc); // This line throws the exception indicating that the transformation did not occur correctly The XML doc is transformed fine using the XMLTransformer class provided by IBM WebSphere. Unfortunately, the WebSphere class only deals with files-- something that we don't want due to I/O processing. We want to transform XML strings instead of files. Am I not understanding something about the JDOM transformation classes or are there future plans to support what we want? A reply to this note would be greatly appreciated. Regards, Salim Hamid IBM Software Group -- Digital Media Development 301-803-1247 T/L 262-1247 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://jdom.org/pipermail/jdom-interest/attachments/20040519/2703c4ce/attachment.htm From laurent.bihanic at atosorigin.com Wed May 19 03:33:38 2004 From: laurent.bihanic at atosorigin.com (Laurent Bihanic) Date: Fri Aug 6 17:09:19 2004 Subject: [jdom-interest] jaxen-jdom.jar in b10 In-Reply-To: References: Message-ID: <40AB3802.3060902@atosorigin.com> Scott Corley wrote: > I am getting the following problem when using xpath (via jaxen) : > > java.lang.NoSuchMethodError: org.jdom.Element.getParent()Lorg/jdom/Element; > at > org.jaxen.jdom.DocumentNavigator.getParentAxisIterator(DocumentNaviga > tor.java:252) [...] > I was wondering if anyone else had run into this or had a solution. This problem comes from the introduction in JDOM b10 of the Parent interface which changed the signature of the getParent() method : For Element, this method now returns a Parent instead of an Element. The only solution is to modify the JDOM DocumentNavigator of Jaxen. The changes are not trivial since the behavior of getParent was changed too (getParent on the root element of a document now returns the Document node instead of null previously). Attached is a patched DocumentNavigator class for JDOM b10 and the corresponding jaxen-jdom.jar. This is a quick fix that needs more testing. Try it a see if it resolves your problem. Laurent -------------- next part -------------- A non-text attachment was scrubbed... Name: jaxen-jdom.jar Type: application/octet-stream Size: 5239 bytes Desc: not available Url : http://jdom.org/pipermail/jdom-interest/attachments/20040519/4637cc88/jaxen-jdom.obj -------------- next part -------------- /* * $Header: /cvsroot/jaxen/jaxen/src/java/main/org/jaxen/jdom/DocumentNavigator.java,v 1.18 2002/04/26 17:17:35 jstrachan Exp $ * $Revision: 1.18 $ * $Date: 2002/04/26 17:17:35 $ * * ==================================================================== * * Copyright (C) 2000-2002 bob mcwhirter & James Strachan. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions, and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions, and the disclaimer that follows * these conditions in the documentation and/or other materials * provided with the distribution. * * 3. The name "Jaxen" must not be used to endorse or promote products * derived from this software without prior written permission. For * written permission, please contact license@jaxen.org. * * 4. Products derived from this software may not be called "Jaxen", nor * may "Jaxen" appear in their name, without prior written permission * from the Jaxen Project Management (pm@jaxen.org). * * In addition, we request (but do not require) that you include in the * end-user documentation provided with the redistribution and/or in the * software itself an acknowledgement equivalent to the following: * "This product includes software developed by the * Jaxen Project (http://www.jaxen.org/)." * Alternatively, the acknowledgment may be graphical using the logos * available at http://www.jaxen.org/ * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE Jaxen AUTHORS OR THE PROJECT * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * ==================================================================== * This software consists of voluntary contributions made by many * individuals on behalf of the Jaxen Project and was originally * created by bob mcwhirter and * James Strachan . For more information on the * Jaxen Project, please see . * * $Id: DocumentNavigator.java,v 1.18 2002/04/26 17:17:35 jstrachan Exp $ */ package org.jaxen.jdom; import org.jaxen.XPath; import org.jaxen.DefaultNavigator; import org.jaxen.FunctionCallException; import org.jaxen.util.SingleObjectIterator; import org.saxpath.SAXPathException; import org.jdom.Parent; import org.jdom.Document; import org.jdom.Element; import org.jdom.Comment; import org.jdom.Text; import org.jdom.Attribute; import org.jdom.CDATA; import org.jdom.ProcessingInstruction; import org.jdom.Namespace; import org.jdom.JDOMException; import org.jdom.input.SAXBuilder; import java.util.HashMap; import java.util.Iterator; import java.util.List; import java.util.Map; /** Interface for navigating around the EXML object model. * *

* This class is not intended for direct usage, but is * used by the Jaxen engine during evaluation. *

* * @see XPath * * @author bob mcwhirter */ public class DocumentNavigator extends DefaultNavigator { /** Singleton implementation. */ private static class Singleton { /** Singleton instance. */ private static DocumentNavigator instance = new DocumentNavigator(); } public static DocumentNavigator getInstance() { return Singleton.instance; } public boolean isElement(Object obj) { return obj instanceof Element; } public boolean isComment(Object obj) { return obj instanceof Comment; } public boolean isText(Object obj) { return ( obj instanceof Text || obj instanceof CDATA ); } public boolean isAttribute(Object obj) { return obj instanceof Attribute; } public boolean isProcessingInstruction(Object obj) { return obj instanceof ProcessingInstruction; } public boolean isDocument(Object obj) { return obj instanceof Document; } public boolean isNamespace(Object obj) { return obj instanceof Namespace || obj instanceof XPathNamespace; } public String getElementName(Object obj) { Element elem = (Element) obj; return elem.getName(); } public String getElementNamespaceUri(Object obj) { Element elem = (Element) obj; String uri = elem.getNamespaceURI(); if ( uri != null && uri.length() == 0 ) return null; else return uri; } public String getAttributeName(Object obj) { Attribute attr = (Attribute) obj; return attr.getName(); } public String getAttributeNamespaceUri(Object obj) { Attribute attr = (Attribute) obj; String uri = attr.getNamespaceURI(); if ( uri != null && uri.length() == 0 ) return null; else return uri; } public Iterator getChildAxisIterator(Object contextNode) { if ( contextNode instanceof Element ) { return ((Element)contextNode).getContent().iterator(); } else if ( contextNode instanceof Document ) { return ((Document)contextNode).getContent().iterator(); } return null; } public Iterator getNamespaceAxisIterator(Object contextNode) { if ( ! ( contextNode instanceof Element ) ) { return null; } Element elem = (Element) contextNode; Map nsMap = new HashMap(); Element current = elem; while ( current != null ) { Namespace ns = current.getNamespace(); if ( ns != Namespace.NO_NAMESPACE ) { if ( !nsMap.containsKey(ns.getPrefix()) ) nsMap.put( ns.getPrefix(), new XPathNamespace(elem, ns) ); } Iterator additional = current.getAdditionalNamespaces().iterator(); while ( additional.hasNext() ) { ns = (Namespace)additional.next(); if ( !nsMap.containsKey(ns.getPrefix()) ) nsMap.put( ns.getPrefix(), new XPathNamespace(elem, ns) ); } current = (Element)((current.getParent() instanceof Element)? current.getParent(): null); } nsMap.put( "xml", new XPathNamespace(elem, Namespace.XML_NAMESPACE) ); return nsMap.values().iterator(); } public Iterator getParentAxisIterator(Object contextNode) { Object parent = null; if ( contextNode instanceof Document ) { parent = contextNode; } else if ( contextNode instanceof Element ) { parent = ((Element)contextNode).getParent(); } else if ( contextNode instanceof Attribute ) { parent = ((Attribute)contextNode).getParent(); } else if ( contextNode instanceof XPathNamespace ) { parent = ((XPathNamespace)contextNode).getJDOMElement(); } else if ( contextNode instanceof ProcessingInstruction ) { parent = ((ProcessingInstruction)contextNode).getParent(); } else if ( contextNode instanceof Comment ) { parent = ((Comment)contextNode).getParent(); } else if ( contextNode instanceof Text ) { parent = ((Text)contextNode).getParent(); } if ( parent != null ) { return new SingleObjectIterator( parent ); } return null; } public Iterator getAttributeAxisIterator(Object contextNode) { if ( ! ( contextNode instanceof Element ) ) { return null; } Element elem = (Element) contextNode; return elem.getAttributes().iterator(); } /** Returns a parsed form of the given xpath string, which will be suitable * for queries on JDOM documents. */ public XPath parseXPath (String xpath) throws SAXPathException { return new JDOMXPath(xpath); } public Object getDocumentNode(Object contextNode) { if ( contextNode instanceof Document ) { return contextNode; } Element elem = (Element) contextNode; return elem.getDocument(); } public String getElementQName(Object obj) { Element elem = (Element) obj; String prefix = elem.getNamespacePrefix(); if ( prefix == null || "".equals( prefix ) ) { return elem.getName(); } return prefix + ":" + elem.getName(); } public String getAttributeQName(Object obj) { Attribute attr = (Attribute) obj; String prefix = attr.getNamespacePrefix(); if ( prefix == null || "".equals( prefix ) ) { return attr.getName(); } return prefix + ":" + attr.getName(); } public String getNamespaceStringValue(Object obj) { if (obj instanceof Namespace) { Namespace ns = (Namespace) obj; return ns.getURI(); } else { XPathNamespace ns = (XPathNamespace) obj; return ns.getJDOMNamespace().getURI(); } } public String getNamespacePrefix(Object obj) { if (obj instanceof Namespace) { Namespace ns = (Namespace) obj; return ns.getPrefix(); } else { XPathNamespace ns = (XPathNamespace) obj; return ns.getJDOMNamespace().getPrefix(); } } public String getTextStringValue(Object obj) { if ( obj instanceof Text ) { return ((Text)obj).getText(); } if ( obj instanceof CDATA ) { return ((CDATA)obj).getText(); } return ""; } public String getAttributeStringValue(Object obj) { Attribute attr = (Attribute) obj; return attr.getValue(); } public String getElementStringValue(Object obj) { Element elem = (Element) obj; StringBuffer buf = new StringBuffer(); List content = elem.getContent(); Iterator contentIter = content.iterator(); Object each = null; while ( contentIter.hasNext() ) { each = contentIter.next(); if ( each instanceof Text ) { buf.append( ((Text)each).getText() ); } else if ( each instanceof CDATA ) { buf.append( ((CDATA)each).getText() ); } else if ( each instanceof Element ) { buf.append( getElementStringValue( each ) ); } } return buf.toString(); } public String getProcessingInstructionTarget(Object obj) { ProcessingInstruction pi = (ProcessingInstruction) obj; return pi.getTarget(); } public String getProcessingInstructionData(Object obj) { ProcessingInstruction pi = (ProcessingInstruction) obj; return pi.getData(); } public String getCommentStringValue(Object obj) { Comment cmt = (Comment) obj; return cmt.getText(); } public String translateNamespacePrefixToUri(String prefix, Object context) { Parent node = null; if ( context instanceof Element ) { node = (Parent) context; } else if ( context instanceof Text ) { node = ((Text)context).getParent(); } else if ( context instanceof Attribute ) { node = ((Attribute)context).getParent(); } else if ( context instanceof XPathNamespace ) { node = ((XPathNamespace)context).getJDOMElement(); } else if ( context instanceof Comment ) { node = ((Comment)context).getParent(); } else if ( context instanceof ProcessingInstruction ) { node = ((ProcessingInstruction)context).getParent(); } if ( node instanceof Element ) { Namespace namespace = ((Element) node).getNamespace( prefix ); if ( namespace != null ) { return namespace.getURI(); } } return null; } public Object getDocument(String url) throws FunctionCallException { try { SAXBuilder builder = new SAXBuilder(); return builder.build( url ); } catch (Exception e) { throw new FunctionCallException( e.getMessage() ); } } } From hamid at us.ibm.com Thu May 20 10:07:13 2004 From: hamid at us.ibm.com (Salim Hamid) Date: Fri Aug 6 17:09:19 2004 Subject: FW: [jdom-interest] Question regarding XML transformation! In-Reply-To: Message-ID: Hello. Just FYI.... The reason the transformation was not working is because my XML contained the tag . Apparently, it is not yet supported by Java 1.4.2 transformation. I would have at least expected an exception. If it is intended to be supported, then I assume it is a bug. Thanks to everyone who responded. Regards, Salim Hamid IBM Software Group -- Digital Media Development 301-803-1247 T/L 262-1247 Phill_Perryman@Mitel.COM Sent by: jdom-interest-admin@jdom.org 05/19/2004 05:18 AM To: jdom-interest@jdom.org cc: Subject: Re: FW: [jdom-interest] Question regarding XML transformation! I use the following which produces an xml output file from a JDOM document (called quote here). The xsl contains the following /** * Produces an export of selected data from the quote (JDOM Document) * into an xml file. */ public void menuFileExport() { enableWaitCursor(); Transformer transformer; FileOutputStream fos = null; try { transformer = TransformerFactory.newInstance().newTransformer( new javax.xml.transform.stream.StreamSource( Global.getRootDir() + "export.xsl")); fos = new FileOutputStream(Global.getReportsDir() + "export.xml"); StreamResult out = new StreamResult(fos); transformer.transform(new JDOMSource(quote), out); fos.flush(); fos.close(); } catch (Exception e) { Global.showErrorMessage( Utility.get( "DialogUnableToCreateReportMessage")); } finally { disableWaitCursor(); } fos = null; transformer = null; } /Phill IS Dept, Software Engineer. phill_perryman@mitel.com http://www.mitel.com Tel: +44 1291 436023 Salim Hamid Sent by: jdom-interest-admin@jdom.org 18/05/2004 19:27 To: jdom-interest@jdom.org, jdom-interest-admin@jdom.org cc: Subject: Re: FW: [jdom-interest] Question regarding XML transformation! Our XSL does not contain "" but it does contain the following: "Robert Taylor" Sent by: jdom-interest-admin@jdom.org 05/18/2004 01:54 PM To: cc: Subject: FW: [jdom-interest] Question regarding XML transformation! I sent this directly to the recipient (by accident) instead of the list. robert -----Original Message----- From: Robert Taylor [mailto:rtaylor@mulework.com] Sent: Tuesday, May 18, 2004 1:27 PM To: Salim Hamid Subject: RE: [jdom-interest] Question regarding XML transformation! This may or may not help, but I get the same exception when I have the following line in my XSL: If I remove that line, then the exception is no longer thrown. hth, robert -----Original Message----- From: jdom-interest-admin@jdom.org [mailto:jdom-interest-admin@jdom.org]On Behalf Of Salim Hamid Sent: Tuesday, May 18, 2004 1:17 PM To: jdom-interest@jdom.org Subject: [jdom-interest] Question regarding XML transformation! We've recently acquired Beta 10 release of JDOM and are interested in the new transformation classes. Do they support transforming an XML doc using an XSL file that I provide? I have the following code but I get the exception "java.lang.IllegalStateException: Root element not set " when I attempt to do anything with the transformed document: XSLTransformer transformer = new XSLTransformer(xslFileName); Document targetDoc = transformer.transform(sourceDoc); System.out.println(targetDoc); // This line throws the exception indicating that the transformation did not occur correctly The XML doc is transformed fine using the XMLTransformer class provided by IBM WebSphere. Unfortunately, the WebSphere class only deals with files-- something that we don't want due to I/O processing. We want to transform XML strings instead of files. Am I not understanding something about the JDOM transformation classes or are there future plans to support what we want? A reply to this note would be greatly appreciated. Regards, Salim Hamid IBM Software Group -- Digital Media Development 301-803-1247 T/L 262-1247 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://jdom.org/pipermail/jdom-interest/attachments/20040520/8031eeb7/attachment.htm From cowtowncoder at yahoo.com Sat May 22 18:53:56 2004 From: cowtowncoder at yahoo.com (Tatu Saloranta) Date: Fri Aug 6 17:09:19 2004 Subject: [jdom-interest] StAXBuilder? Message-ID: <20040523015356.40557.qmail@web41711.mail.yahoo.com> Apologies if this is a FAQ (tried to look for it, only found couple of matches to StAX in general), but are there plans to have a StAXBuilder (along with SAXBuilder and DOMBuilder), to be able to construct Jdom documents from StAX readers? It seems to me like writing one should be fairly easy thing to do (looking at DOMBuilder). One potential issue is that if such builder was created, how could/should it be packaged. Since it'd have dependency to StAX API, which is not part of JDK at this point, would this require it be part of contributed code? -+ Tatu +- __________________________________ Do you Yahoo!? Yahoo! Domains � Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer From jhunter at xquery.com Sun May 23 07:16:37 2004 From: jhunter at xquery.com (Jason Hunter) Date: Fri Aug 6 17:09:19 2004 Subject: [jdom-interest] StAXBuilder? In-Reply-To: <20040523015356.40557.qmail@web41711.mail.yahoo.com> References: <20040523015356.40557.qmail@web41711.mail.yahoo.com> Message-ID: <40B0B245.1020905@xquery.com> Tatu Saloranta wrote: > Apologies if this is a FAQ (tried to look for it, only > found couple of matches to StAX in general), but are > there plans to have a StAXBuilder (along with > SAXBuilder and DOMBuilder), to be able to construct > Jdom documents from StAX readers? It seems to me like > writing one should be fairly easy thing to do (looking > at DOMBuilder). I know of no one working on such a builder. I agree it could be useful. If you want to work on it, feel free. > One potential issue is that if such builder was > created, how could/should it be packaged. Since it'd > have dependency to StAX API, which is not part of JDK > at this point, would this require it be part of > contributed code? Not necessarily. -jh- From cowtowncoder at yahoo.com Sun May 23 18:28:27 2004 From: cowtowncoder at yahoo.com (Tatu Saloranta) Date: Fri Aug 6 17:09:19 2004 Subject: [jdom-interest] StAXBuilder? In-Reply-To: <40B0B245.1020905@xquery.com> Message-ID: <20040524012827.5160.qmail@web41712.mail.yahoo.com> ... > I know of no one working on such a builder. I agree > it could be useful. > If you want to work on it, feel free. Ok, I can give it a try, starting with builder, and if that goes ok, then the reverse. -+ Tatu +- __________________________________ Do you Yahoo!? Yahoo! Domains � Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer From Phill_Perryman at Mitel.COM Mon May 24 05:07:48 2004 From: Phill_Perryman at Mitel.COM (Phill_Perryman@Mitel.COM) Date: Fri Aug 6 17:09:19 2004 Subject: [jdom-interest] Web Site Message-ID: Where has www.jdom.org gone, I cannot get hold of the javadocs /Phill IS Dept, Software Engineer. phill_perryman@mitel.com http://www.mitel.com Tel: +44 1291 436023 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://jdom.org/pipermail/jdom-interest/attachments/20040524/d03fb695/attachment.htm