From thomas.scheffler at uni-jena.de Thu Aug 4 00:07:54 2011 From: thomas.scheffler at uni-jena.de (Thomas Scheffler) Date: Thu, 04 Aug 2011 09:07:54 +0200 Subject: [jdom-interest] Parsing a MODS-document with validation fails In-Reply-To: <4E2D3584.1070007@uni-jena.de> References: <4E26D6E5.2010309@uni-jena.de> <4E27DFEC.80902@uni-jena.de> <4E2922F6.2020506@uni-jena.de> <4E29E6E7.9080708@uni-jena.de> <4E2D159C.30802@uni-jena.de> <4E2D3584.1070007@uni-jena.de> Message-ID: <4E3A454A.60304@uni-jena.de> Am 25.07.2011 11:21, schrieb Thomas Scheffler: > Am 25.07.2011 09:05, schrieb Thomas Scheffler: >> Am 24.07.2011 23:46, schrieb Bradley S. Huffman: >>> And if the prefix "ns1" is already mapped to another URI because the >>> user decided to use "ns1" as a prefix, what kind of havoc will this >>> cause? >> >> I got your point! We have to check if "ns"+nsPrefixCount is already >> defined, if we create it. I do not know though if that is enough. We can >> do this for the current element and be sure of that. But if for instance >> we have three tag: "a","b","c", where "a" is parent of "b" an that is >> parent of "c". There could be an issue if "a" defines a namespace with >> prefix "ns?" that is in use by "c" and not by "b". >> When it comes to "b" we see the namespace prefix is currently undefined. >> And bound it to the new uri. This way the namespace in c changes. >> So we have to drag every usage of a prefix throughout the document with >> the "endPrefixMapping" event, that is currently missing an >> implementation in SAXHandler. >> Do you agree? > > I prepared a new version of the patch that uses the "endPrefixMapping" > event to handle namespace prefixes and also checks if "ns"+nsPrefixCount > is already defined. Hi, are there any news about integrating my patch? Locally it is running fine. If you find any issues I am willing to work on that. regards, Thomas From jhunter at servlets.com Thu Aug 4 13:45:02 2011 From: jhunter at servlets.com (Jason Hunter) Date: Thu, 4 Aug 2011 16:45:02 -0400 Subject: [jdom-interest] Parsing a MODS-document with validation fails In-Reply-To: <4E3A454A.60304@uni-jena.de> References: <4E26D6E5.2010309@uni-jena.de> <4E27DFEC.80902@uni-jena.de> <4E2922F6.2020506@uni-jena.de> <4E29E6E7.9080708@uni-jena.de> <4E2D159C.30802@uni-jena.de> <4E2D3584.1070007@uni-jena.de> <4E3A454A.60304@uni-jena.de> Message-ID: <8B4F14D5-F637-488A-A231-DA73B28166C6@servlets.com> > Hi, > > are there any news about integrating my patch? Locally it is running fine. If you find any issues I am willing to work on that. Brad wanted to check if it was an issue with JDOM or the SAX parser underneath. He hasn't done it yet, nor have I. Perhaps you want to test that out, if you beat us to it. It'd also be good if there way a way to solve this issue without inventing namespaces. -jh- From thomas.scheffler at uni-jena.de Thu Aug 4 23:25:33 2011 From: thomas.scheffler at uni-jena.de (Thomas Scheffler) Date: Fri, 05 Aug 2011 08:25:33 +0200 Subject: [jdom-interest] Parsing a MODS-document with validation fails In-Reply-To: <8B4F14D5-F637-488A-A231-DA73B28166C6@servlets.com> References: <4E26D6E5.2010309@uni-jena.de> <4E27DFEC.80902@uni-jena.de> <4E2922F6.2020506@uni-jena.de> <4E29E6E7.9080708@uni-jena.de> <4E2D159C.30802@uni-jena.de> <4E2D3584.1070007@uni-jena.de> <4E3A454A.60304@uni-jena.de> <8B4F14D5-F637-488A-A231-DA73B28166C6@servlets.com> Message-ID: <4E3B8CDD.4080301@uni-jena.de> Am 04.08.2011 22:45, schrieb Jason Hunter: >> Hi, >> >> are there any news about integrating my patch? Locally it is >> running fine. If you find any issues I am willing to work on that. > > Brad wanted to check if it was an issue with JDOM or the SAX parser > underneath. He hasn't done it yet, nor have I. Perhaps you want to > test that out, if you beat us to it. > > It'd also be good if there way a way to solve this issue without > inventing namespaces. This is how it is done when using DOM. For the sample MODS document from the first post the namespace will be resolved to the "correct" prefix "xlink", while DOM will generate "ns0:type". The "invent" mechanism is there as a fallback as it is better to invent a prefix than using the default namespace. Here is the code for DOM: DocumentBuilderFactory builderFactory = DocumentBuilderFactory.newInstance(); builderFactory.setNamespaceAware(true); builderFactory.setValidating(true); builderFactory.setFeature("http://apache.org/xml/features/validation/schema", true); DocumentBuilder builder2 = builderFactory.newDocumentBuilder(); builder2.setEntityResolver(er); org.w3c.dom.Document document2 = builder2.parse("http://academiccommons.columbia.edu/download/fedora_content/show_pretty/ac:111060/CONTENT/ac111060_description.xml"); DOMSource domSource = new DOMSource(document2); StreamResult result = new StreamResult(System.out); TransformerFactory tf = TransformerFactory.newInstance(); Transformer transformer = tf.newTransformer(); transformer.setOutputProperty(OutputKeys.INDENT, "yes"); transformer.transform(domSource, result); and it will generate this output: Edwards Stephen A. author Columbia University. Computer Science Using just the QName ought to be enough (that is why it's called qualified) but it shows that at least with xerces from JRE and in the current version it isn't. So either call my patch a fix or a workaround. regards, Thomas From bshuffman at gmail.com Sun Aug 7 12:42:44 2011 From: bshuffman at gmail.com (Bradley S. Huffman) Date: Sun, 7 Aug 2011 14:42:44 -0500 Subject: [jdom-interest] Parsing a MODS-document with validation fails In-Reply-To: <4E3B8CDD.4080301@uni-jena.de> References: <4E26D6E5.2010309@uni-jena.de> <4E27DFEC.80902@uni-jena.de> <4E2922F6.2020506@uni-jena.de> <4E29E6E7.9080708@uni-jena.de> <4E2D159C.30802@uni-jena.de> <4E2D3584.1070007@uni-jena.de> <4E3A454A.60304@uni-jena.de> <8B4F14D5-F637-488A-A231-DA73B28166C6@servlets.com> <4E3B8CDD.4080301@uni-jena.de> Message-ID: I did a simple test and printed out what was being given to SAXHandler by the parser. Sure enough, on this document when validation is turn on, the SAX parser is reporting two attributes with the same qname (which happens to be the local name since they are both unprefix), but in different namespaces. JDOM should take the events as presented and build a object tree to represent it. It shouldn't "generate" anything. However, in this case I don't know who to point the finger at, but it's not JDOM. Elliotte, are you still lurking around? ******************************************** namespaceURI = http://www.loc.gov/mods/v3 localName = name qName = name attribute local name = type attribute qname = type attribute uri = attribute type = CDATA attribute value = personal attribute local name = type attribute qname = type attribute uri = http://www.w3.org/1999/xlink attribute type = CDATA attribute value = simple ******************************************** namespaceURI = http://www.loc.gov/mods/v3 localName = namePart qName = namePart attribute local name = type attribute qname = type attribute uri = attribute type = CDATA attribute value = family From jhunter at servlets.com Sun Aug 7 18:32:23 2011 From: jhunter at servlets.com (Jason Hunter) Date: Sun, 7 Aug 2011 18:32:23 -0700 Subject: [jdom-interest] jdom 2.0 with generics In-Reply-To: <27527DC0-3636-427E-BB26-EDF42662523B@servlets.com> References: <4E282315.1050701@peralex.com> <4E2832EE.7010209@uni-jena.de><4E284487.7060602@jalios.com> <7371847E-4174-4356-82DA-205087597E92@activemath.org> <4E28B3F6.9080501@tuis.net> <4E28BC97.80402@tuis.net> <27527DC0-3636-427E-BB26-EDF42662523B@servlets.com> Message-ID: I thought I'd send a status update on JDOM 2.0... In the last couple weeks I've setup a GitHub repository for the work at https://github.com/hunterhacker/jdom. Rolf was able to import the CVS history fully into GitHub. If you're curious how, he wrote a wiki page in the project. The project has branches for 1.0, 1.1, and 1.1.1. The master branch is for 2.0 work, now underway. Here's a list of improvements we might make (feedback welcome): https://github.com/hunterhacker/jdom/wiki/JDOM-2.0 A list of outstanding bugs and RFEs: https://github.com/hunterhacker/jdom/issues If you're new to GitHub one of the perks is you can "watch" the project to see what's happening. You can also fork the project, make changes, and send us a pull request to incorporate your change into the official tree. That's ideal for simple bug fixes or even major Java 5 feature adjustments where you might want to work in isolation for a while. You can follow the project on Twitter at: http://twitter.com/#!/jdomproject And see all commits at: http://twitter.com/#!/jdomcommits We're looking for others who want to be heavily involved in the Java 5 work. Speak up if that's you. -jh- On Jul 22, 2011, at 1:33 PM, Jason Hunter wrote: > Rolf's been sending in good code for as long as I can remember. :) > > The reason I've resisted jumping on generics was the backward compatibility problem. It's just something you can do without breaking old code, as Rolf's email explains in some good detail. > > I do think it's causing JDOM to be seen in a negative light, so we should do something about it. > > The alternative package approach is probably the best road forward. It's a bit uglier, but it makes explicit the breakage, and means you can use JDOM 1.1 and JDOM 2.0 classes in the same project without conflict (an issue that arises if a project uses both Library X and Library Y which both depend on JDOM and maybe not the same versions). > > I suppose org.jdom2 is the best package. Suitable for a 2.0 release. > > I don't have a lot of time to do coding but I'll be happy to coordinate. Rolf, why don't you send me the code and I'll put it in revision control. Some others have sent in versions as well. We can decide which one's best and work on a 2.0 release. > > Maybe we should move the code to github while we're at it? > > Send in thoughts... > > -jh- > > On Jul 21, 2011, at 4:56 PM, Rolf Lear wrote: > >> As an overview of what I did: >> >> README.Java5 >> ============ >> >> Here are the more significant changes made for the Java5 proposed solution. >> >> 1. Modified org.jdom.filter.Filter to be generic. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> This allows Filter Implementations to return specific Content types. >> In addition, instead of returning boolean, it instead must fulfill the contract to return the input content cast in to >> the same type as the Filter . Returning a null value indicates the filter does not match. >> >> public interface Filter extends java.io.Serializable { >> public T filter(Content content); >> } >> >> Here is the JDom1.1 interface: >> public interface Filter extends java.io.Serializable { >> public boolean matches(Object obj); >> } >> >> Significant implications of this change include the change of the method name from 'matches' to 'filter'. >> This is somewhat mitigated by the 'AbstractFilter' method 'matches' which is simply: >> return filter(content) != null; >> >> Another 'regression' is that the filter and matches method now require at least 'Content' instead of 'Object' data. >> A direct implication of this is that you can not have a Filter on Document Objects. I could not find any examples of >> this in the project, or my work environment. It seems to be somewhat 'safe'. This is especially true because Filters >> are primarily used as input to the Parent.getContent(Filter) method, which, since the content can never be Document, >> implies this change is probably benign. It does make some code redundant in class ContentFilter. >> >> All classes that implement Filter have been modified to be sensible. >> >> This is the change that makes the code: >> List kids = someelement.getChildren(); >> possible. >> >> >> 2. Modified Parent to be generic. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> This allows for the method: >> Parent addContent(Content content) >> to be added to the Parent interface, and still return the right type... >> >> >> 2. Rewrote much of ContentList (again) >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> Three motivators for this change: >> a) Generics - so much had to change to accomodate Generics, seems this was the core impact. >> b) Compliance - set() method on Collections are not supposed to impact Concurrent Modification, >> but JDom did. Changed this so that set() does not impact concurrent status. >> c) Performance - modified FilterList and FilterListIterator to work on an as-needed basis. Will >> cache known content, but will only filter data on an as-needed basis, or 'lazy' basis. Need to >> devise tests to measure performance impact, but things like element.getChildren.iterator() will be >> much faster. >> >> Another motivator was conformance with existing concepts, specifically List.subList(int,int). The paradigm for >> SubList is that modifications to the base list would cause concurrent exception in subList. This seems to be >> appropriate for FilterLists too, but, too much code depends on essentially dynamic/concurrent modification >> to make the change. The old behaviour remains.... leading to potentially odd things in FilterList iterators. >> >> >> 3. Removed complexities in JDOMException >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> In Java5 we have the initCause method embedded in to Throwable. We don't need to jump through hoops any more. >> >> >> 4. Removed TextBuffer class >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> This was an attempt to be a better performing StringBuffer. With Java5's StringBuilder, we don't need to worry. >> >> >> 5. Created AttributeType Enum >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> This makes new attributes easy to manage, and also eliminates a bunch of org.jdom.test.* stuff. >> This also has probably the largest impact on existing code because of the requriement to change things like >> Attribute att = new Attribute ("name", "somevalue", Attribute.ID_TYPE); >> to >> Attribute att = new Attribute ("name", "somevalue", AttributeType.ID_TYPE); >> >> On the other hand, it is all now TypeSafe ;-) >> >> >> 6. Created Annotation CVS_ID >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> This is used instead of the static field CVS_ID. This is set up to be an annotation to a class. Previously we had: >> public class Attribute implements Serializable, Cloneable { >> private static final String CVS_ID = "@(#) $RCSfile: Attribute.java,v $ $Revision: 1.56 $ $Date: 2007/11/10 05:28:58 $ $Name: $"; >> .... >> >> we now instead have: >> @CVS_ID("@(#) $RCSfile: Attribute.java,v $ $Revision: 1.56 $ $Date: 2007/11/10 05:28:58 $ $Name: $") >> public class Attribute implements Serializable, Cloneable { >> >> The motivation for this is because Eclipse complains when there are unused private members... but, this is perfect >> fodder for annotations. >> >> As a result, all org.jdom.* classes in the main repo have been modified to use the annotation rather than the static String. >> >> As an excercies later, we will be able to programatically be able to determing all the CVS details at runtime using >> the annotations, and I have tested that >> >> >> 7. General Tidy-up. >> ^^^^^^^^^^^^^^^^^^^ >> >> Fixed all JavaDoc comments where applicable. Ensured @Override was specified where appropriate, etc. >> basically, I set strict rules in Eclipse, and then fixed all issues. >> >> >> 8. JavaDoc >> ^^^^^^^^^^ >> All public and protected classes, methods, and fields have had their JavaDoc entries inspected and completed. >> >> >> 9. build.xml >> ^^^^^^^^^^^^ >> >> set Java compliance levels, JDom version number. >> >> TESTS >> ===== >> org.jdom.test.* has been modified to use and test the new code properly. >> Alltests was modified to include some suites that were not included. >> Alltests has been run, and all run tests have passed. >> >> >> CONTRIB >> ======= >> All code has been modified to do what appears to be sane usage of the new JDom, but testing has not been done. >> >> STILL TO DO >> =========== >> >> FilterIterator seems clunky still. Especially the XXX warning. >> >> >> >> >> >> >> >> On 21/07/2011 7:19 PM, Rolf Lear wrote: >>> >>> I did a JDOM conversion a while back. Made the code available to those who were interested. >>> >>> There are a few 'gotchas', and most of the Generics implementation relies on 'hiding' explicit casting inside of the ContentList class. >>> >>> It makes code that compiles against the JDOM cleaner, but does not actually improve any reliability... >>> >>> Additionally, the XPath support is pretty much impossible to accomplish. >>> >>> Let me dig up the code.... Or, rather, anyone interested should mail me directly. >>> >>> Rolf >>> >> >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From jhunter at servlets.com Sun Aug 7 20:34:47 2011 From: jhunter at servlets.com (Jason Hunter) Date: Sun, 7 Aug 2011 20:34:47 -0700 Subject: [jdom-interest] Parsing a MODS-document with validation fails In-Reply-To: References: <4E26D6E5.2010309@uni-jena.de> <4E27DFEC.80902@uni-jena.de> <4E2922F6.2020506@uni-jena.de> <4E29E6E7.9080708@uni-jena.de> <4E2D159C.30802@uni-jena.de> <4E2D3584.1070007@uni-jena.de> <4E3A454A.60304@uni-jena.de> <8B4F14D5-F637-488A-A231-DA73B28166C6@servlets.com> <4E3B8CDD.4080301@uni-jena.de> Message-ID: <119D72CF-1AA2-4969-9D72-A243FF8F5B7C@servlets.com> I tested the same thing with DOMBuilder. It shows two attributes with the same name on the same element. name: type value: simple name: type value: personal My guess is in Thomas' sample code it's the transform action that did the ns0 addition. JDOM doesn't error out when it sees this, the code just lets setAttribute() overwrite any previous assignments. It seems like the input is technically malformed. Has there been official advice given on what an object model should do in this case? -jh- On Aug 7, 2011, at 12:42 PM, Bradley S. Huffman wrote: > I did a simple test and printed out what was being given to SAXHandler > by the parser. Sure enough, on this document when validation is turn > on, the SAX parser is reporting two attributes with the same qname > (which happens to be the local name since they are both unprefix), but > in different namespaces. > > JDOM should take the events as presented and build a object tree to > represent it. It shouldn't "generate" anything. However, in this > case I don't know who to point the finger at, but it's not JDOM. > > Elliotte, are you still lurking around? > > ******************************************** > namespaceURI = http://www.loc.gov/mods/v3 > localName = name > qName = name > attribute local name = type > attribute qname = type > attribute uri = > attribute type = CDATA > attribute value = personal > attribute local name = type > attribute qname = type > attribute uri = http://www.w3.org/1999/xlink > attribute type = CDATA > attribute value = simple > ******************************************** > namespaceURI = http://www.loc.gov/mods/v3 > localName = namePart > qName = namePart > attribute local name = type > attribute qname = type > attribute uri = > attribute type = CDATA > attribute value = family > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From thomas.scheffler at uni-jena.de Sun Aug 7 23:00:20 2011 From: thomas.scheffler at uni-jena.de (Thomas Scheffler) Date: Mon, 08 Aug 2011 08:00:20 +0200 Subject: [jdom-interest] Parsing a MODS-document with validation fails In-Reply-To: <4E3F5ED2.4040509@tuis.net> References: <4E26D6E5.2010309@uni-jena.de> <4E27DFEC.80902@uni-jena.de> <4E2922F6.2020506@uni-jena.de> <4E29E6E7.9080708@uni-jena.de> <4E2D159C.30802@uni-jena.de> <4E2D3584.1070007@uni-jena.de> <4E3A454A.60304@uni-jena.de> <8B4F14D5-F637-488A-A231-DA73B28166C6@servlets.com> <4E3B8CDD.4080301@uni-jena.de> <119D72CF-1AA2-4969-9D72-A243FF8F5B7C@servlets.com> <4E3F5ED2.4040509@tuis.net> Message-ID: <4E3F7B74.8010506@uni-jena.de> Am 08.08.2011 05:58, schrieb Rolf: > But, as for the ns0 'default' name, I think that is a poor solution, and > that it should be possible to scan up the tree to find a real prefix for > that namespace... If the parser is not going to provide it, I think the > JDOM SAX Handler can fall back on a work-around solution that does not > 'lose' the attribute - a solution that is a combination of Thomas's fix, > and a smarter prefix determination routine. Hi, that is exactly what "nsURIMapping" and "usedNamespaces" does. On "startPrefixMapping()" a prefixMapping is assigned and kept until "endPrefixMapping()" called. In unpatched state SAXHandler cleaned those mappings after every element, there was no "endPrefixMapping" handler. The "ns[0-9]+" case is a fallback that is not even used in the MODS-case as "xlink" could be resolved properly. It is just in the code to definitively not overwrite an attribute in the default namespace. Hope that clarifies my 2nd patch (2001-07-25) a bit. regards, Thomas From bcox at virtualschool.edu Mon Aug 8 04:10:34 2011 From: bcox at virtualschool.edu (Brad Cox) Date: Mon, 8 Aug 2011 07:10:34 -0400 Subject: [jdom-interest] jdom 2.0 with generics In-Reply-To: References: <4E282315.1050701@peralex.com> <4E2832EE.7010209@uni-jena.de> <4E284487.7060602@jalios.com> <7371847E-4174-4356-82DA-205087597E92@activemath.org> <4E28B3F6.9080501@tuis.net> <4E28BC97.80402@tuis.net> <27527DC0-3636-427E-BB26-EDF42662523B@servlets.com> Message-ID: Any interest in some simple additions (trivial pom.xml files) to build jdom with maven? If so, I'll need a recipe for how to push changes via git. I use mercurial for everything else. After years of tolerating W3C DOM, JDOM was like coming home again! Thanks for resurrecting this! On Sun, Aug 7, 2011 at 9:32 PM, Jason Hunter wrote: > I thought I'd send a status update on JDOM 2.0... > > In the last couple weeks I've setup a GitHub repository for the work at > https://github.com/hunterhacker/jdom. Rolf was able to import the CVS > history fully into GitHub. If you're curious how, he wrote a wiki page in > the project. > > The project has branches for 1.0, 1.1, and 1.1.1. The master branch is for > 2.0 work, now underway. > > Here's a list of improvements we might make (feedback welcome): > https://github.com/hunterhacker/jdom/wiki/JDOM-2.0 > > A list of outstanding bugs and RFEs: > https://github.com/hunterhacker/jdom/issues > > If you're new to GitHub one of the perks is you can "watch" the project to > see what's happening. You can also fork the project, make changes, and send > us a pull request to incorporate your change into the official tree. That's > ideal for simple bug fixes or even major Java 5 feature adjustments where > you might want to work in isolation for a while. > > You can follow the project on Twitter at: > http://twitter.com/#!/jdomproject > > And see all commits at: > http://twitter.com/#!/jdomcommits > > We're looking for others who want to be heavily involved in the Java 5 > work. Speak up if that's you. > > -jh- > > On Jul 22, 2011, at 1:33 PM, Jason Hunter wrote: > > > Rolf's been sending in good code for as long as I can remember. :) > > > > The reason I've resisted jumping on generics was the backward > compatibility problem. It's just something you can do without breaking old > code, as Rolf's email explains in some good detail. > > > > I do think it's causing JDOM to be seen in a negative light, so we should > do something about it. > > > > The alternative package approach is probably the best road forward. It's > a bit uglier, but it makes explicit the breakage, and means you can use JDOM > 1.1 and JDOM 2.0 classes in the same project without conflict (an issue that > arises if a project uses both Library X and Library Y which both depend on > JDOM and maybe not the same versions). > > > > I suppose org.jdom2 is the best package. Suitable for a 2.0 release. > > > > I don't have a lot of time to do coding but I'll be happy to coordinate. > Rolf, why don't you send me the code and I'll put it in revision control. > Some others have sent in versions as well. We can decide which one's best > and work on a 2.0 release. > > > > Maybe we should move the code to github while we're at it? > > > > Send in thoughts... > > > > -jh- > > > > On Jul 21, 2011, at 4:56 PM, Rolf Lear wrote: > > > >> As an overview of what I did: > >> > >> README.Java5 > >> ============ > >> > >> Here are the more significant changes made for the Java5 proposed > solution. > >> > >> 1. Modified org.jdom.filter.Filter to be generic. > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> This allows Filter Implementations to return specific Content types. > >> In addition, instead of returning boolean, it instead must fulfill the > contract to return the input content cast in to > >> the same type as the Filter . Returning a null value indicates the > filter does not match. > >> > >> public interface Filter extends java.io.Serializable > { > >> public T filter(Content content); > >> } > >> > >> Here is the JDom1.1 interface: > >> public interface Filter extends java.io.Serializable { > >> public boolean matches(Object obj); > >> } > >> > >> Significant implications of this change include the change of the method > name from 'matches' to 'filter'. > >> This is somewhat mitigated by the 'AbstractFilter' method 'matches' > which is simply: > >> return filter(content) != null; > >> > >> Another 'regression' is that the filter and matches method now require > at least 'Content' instead of 'Object' data. > >> A direct implication of this is that you can not have a Filter on > Document Objects. I could not find any examples of > >> this in the project, or my work environment. It seems to be somewhat > 'safe'. This is especially true because Filters > >> are primarily used as input to the Parent.getContent(Filter) method, > which, since the content can never be Document, > >> implies this change is probably benign. It does make some code redundant > in class ContentFilter. > >> > >> All classes that implement Filter have been modified to be sensible. > >> > >> This is the change that makes the code: > >> List kids = someelement.getChildren(); > >> possible. > >> > >> > >> 2. Modified Parent to be generic. > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> > >> This allows for the method: > >> Parent addContent(Content content) > >> to be added to the Parent interface, and still return the right type... > >> > >> > >> 2. Rewrote much of ContentList (again) > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> Three motivators for this change: > >> a) Generics - so much had to change to accomodate Generics, seems this > was the core impact. > >> b) Compliance - set() method on Collections are not supposed to impact > Concurrent Modification, > >> but JDom did. Changed this so that set() does not impact concurrent > status. > >> c) Performance - modified FilterList and FilterListIterator to work on > an as-needed basis. Will > >> cache known content, but will only filter data on an as-needed > basis, or 'lazy' basis. Need to > >> devise tests to measure performance impact, but things like > element.getChildren.iterator() will be > >> much faster. > >> > >> Another motivator was conformance with existing concepts, specifically > List.subList(int,int). The paradigm for > >> SubList is that modifications to the base list would cause concurrent > exception in subList. This seems to be > >> appropriate for FilterLists too, but, too much code depends on > essentially dynamic/concurrent modification > >> to make the change. The old behaviour remains.... leading to potentially > odd things in FilterList iterators. > >> > >> > >> 3. Removed complexities in JDOMException > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> In Java5 we have the initCause method embedded in to Throwable. We don't > need to jump through hoops any more. > >> > >> > >> 4. Removed TextBuffer class > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> This was an attempt to be a better performing StringBuffer. With Java5's > StringBuilder, we don't need to worry. > >> > >> > >> 5. Created AttributeType Enum > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> This makes new attributes easy to manage, and also eliminates a bunch of > org.jdom.test.* stuff. > >> This also has probably the largest impact on existing code because of > the requriement to change things like > >> Attribute att = new Attribute ("name", "somevalue", > Attribute.ID_TYPE); > >> to > >> Attribute att = new Attribute ("name", "somevalue", > AttributeType.ID_TYPE); > >> > >> On the other hand, it is all now TypeSafe ;-) > >> > >> > >> 6. Created Annotation CVS_ID > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> This is used instead of the static field CVS_ID. This is set up to be an > annotation to a class. Previously we had: > >> public class Attribute implements Serializable, Cloneable { > >> private static final String CVS_ID = "@(#) $RCSfile: > Attribute.java,v $ $Revision: 1.56 $ $Date: 2007/11/10 05:28:58 $ $Name: > $"; > >> .... > >> > >> we now instead have: > >> @CVS_ID("@(#) $RCSfile: Attribute.java,v $ $Revision: 1.56 $ $Date: > 2007/11/10 05:28:58 $ $Name: $") > >> public class Attribute implements Serializable, Cloneable { > >> > >> The motivation for this is because Eclipse complains when there are > unused private members... but, this is perfect > >> fodder for annotations. > >> > >> As a result, all org.jdom.* classes in the main repo have been modified > to use the annotation rather than the static String. > >> > >> As an excercies later, we will be able to programatically be able to > determing all the CVS details at runtime using > >> the annotations, and I have tested that > >> > >> > >> 7. General Tidy-up. > >> ^^^^^^^^^^^^^^^^^^^ > >> > >> Fixed all JavaDoc comments where applicable. Ensured @Override was > specified where appropriate, etc. > >> basically, I set strict rules in Eclipse, and then fixed all issues. > >> > >> > >> 8. JavaDoc > >> ^^^^^^^^^^ > >> All public and protected classes, methods, and fields have had their > JavaDoc entries inspected and completed. > >> > >> > >> 9. build.xml > >> ^^^^^^^^^^^^ > >> > >> set Java compliance levels, JDom version number. > >> > >> TESTS > >> ===== > >> org.jdom.test.* has been modified to use and test the new code properly. > >> Alltests was modified to include some suites that were not included. > >> Alltests has been run, and all run tests have passed. > >> > >> > >> CONTRIB > >> ======= > >> All code has been modified to do what appears to be sane usage of the > new JDom, but testing has not been done. > >> > >> STILL TO DO > >> =========== > >> > >> FilterIterator seems clunky still. Especially the XXX warning. > >> > >> > >> > >> > >> > >> > >> > >> On 21/07/2011 7:19 PM, Rolf Lear wrote: > >>> > >>> I did a JDOM conversion a while back. Made the code available to those > who were interested. > >>> > >>> There are a few 'gotchas', and most of the Generics implementation > relies on 'hiding' explicit casting inside of the ContentList class. > >>> > >>> It makes code that compiles against the JDOM cleaner, but does not > actually improve any reliability... > >>> > >>> Additionally, the XPath support is pretty much impossible to > accomplish. > >>> > >>> Let me dig up the code.... Or, rather, anyone interested should mail me > directly. > >>> > >>> Rolf > >>> > >> > >> _______________________________________________ > >> To control your jdom-interest membership: > >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > > > > > > _______________________________________________ > > To control your jdom-interest membership: > > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > -- Cell: 703-594-1883 Blog: http://bradjcox.blogspot.com Web: http://virtualschool.edu Manassas VA 20111 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdom at tuis.net Mon Aug 8 05:52:24 2011 From: jdom at tuis.net (jdom) Date: Mon, 08 Aug 2011 08:52:24 -0400 Subject: [jdom-interest] jdom 2.0 with generics In-Reply-To: References: <4E282315.1050701@peralex.com> <4E2832EE.7010209@uni-jena.de> <4E284487.7060602@jalios.com> <7371847E-4174-4356-82DA-205087597E92@activemath.org> <4E28B3F6.9080501@tuis.net> <4E28BC97.80402@tuis.net> <27527DC0-3636-427E-BB26-EDF42662523B@servlets.com> Message-ID: <3b9934f544c3719131b24b4aa4e22408@tuis.net> Hi Brad In the short term it is unlikely that the JDOM repo will be converted to a maven-style build. I simply do not use maven at all, and I do not know the maven 'paradigm'. I know that the possibility is there to produe the maven co-ordinates for the JDOM releases, but it woul dmake sense to first get something usable out of JDOM2 before we go publishing it as a maven resource. Bottom line is that, if it happens, it will be one of the last things to go through. Probably only after the alpha/beta/final stages of JDOM2 are settled. Still, JDOM is all about 'Java manipulation of XML made easy', so, it should be considered, and I've updated the wiki page https://github.com/hunterhacker/jdom/wiki/JDOM-2.0 to reflect that Maven artifacts should be a possible goal of JDOM2. Pleased to see the mounting excitement for JDOM2. Rolf On Mon, 8 Aug 2011 07:10:34 -0400, Brad Cox wrote: > Any interest in some simple additions (trivial pom.xml files) to build jdom > with maven? > > If so, I'll need a recipe for how to push changes via git. I use mercurial > for everything else. > > After years of tolerating W3C DOM, JDOM was like coming home again! Thanks > for resurrecting this! > > On Sun, Aug 7, 2011 at 9:32 PM, Jason Hunter wrote: > >> I thought I'd send a status update on JDOM 2.0... >> >> In the last couple weeks I've setup a GitHub repository for the work at >> https://github.com/hunterhacker/jdom. Rolf was able to import the CVS >> history fully into GitHub. If you're curious how, he wrote a wiki page >> in >> the project. >> >> The project has branches for 1.0, 1.1, and 1.1.1. The master branch is >> for >> 2.0 work, now underway. >> >> Here's a list of improvements we might make (feedback welcome): >> https://github.com/hunterhacker/jdom/wiki/JDOM-2.0 >> >> A list of outstanding bugs and RFEs: >> https://github.com/hunterhacker/jdom/issues >> >> If you're new to GitHub one of the perks is you can "watch" the project >> to >> see what's happening. You can also fork the project, make changes, and >> send >> us a pull request to incorporate your change into the official tree. >> That's >> ideal for simple bug fixes or even major Java 5 feature adjustments where >> you might want to work in isolation for a while. >> >> You can follow the project on Twitter at: >> http://twitter.com/#!/jdomproject >> >> And see all commits at: >> http://twitter.com/#!/jdomcommits >> >> We're looking for others who want to be heavily involved in the Java 5 >> work. Speak up if that's you. >> >> -jh- >> >> On Jul 22, 2011, at 1:33 PM, Jason Hunter wrote: >> >> > Rolf's been sending in good code for as long as I can remember. :) >> > >> > The reason I've resisted jumping on generics was the backward >> compatibility problem. It's just something you can do without breaking >> old >> code, as Rolf's email explains in some good detail. >> > >> > I do think it's causing JDOM to be seen in a negative light, so we >> > should >> do something about it. >> > >> > The alternative package approach is probably the best road forward. >> > It's >> a bit uglier, but it makes explicit the breakage, and means you can use >> JDOM >> 1.1 and JDOM 2.0 classes in the same project without conflict (an issue >> that >> arises if a project uses both Library X and Library Y which both depend >> on >> JDOM and maybe not the same versions). >> > >> > I suppose org.jdom2 is the best package. Suitable for a 2.0 release. >> > >> > I don't have a lot of time to do coding but I'll be happy to >> > coordinate. >> Rolf, why don't you send me the code and I'll put it in revision >> control. >> Some others have sent in versions as well. We can decide which one's >> best >> and work on a 2.0 release. >> > >> > Maybe we should move the code to github while we're at it? >> > >> > Send in thoughts... >> > >> > -jh- >> > >> > On Jul 21, 2011, at 4:56 PM, Rolf Lear wrote: >> > >> >> As an overview of what I did: >> >> >> >> README.Java5 >> >> ============ >> >> >> >> Here are the more significant changes made for the Java5 proposed >> solution. >> >> >> >> 1. Modified org.jdom.filter.Filter to be generic. >> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> This allows Filter Implementations to return specific Content types. >> >> In addition, instead of returning boolean, it instead must fulfill the >> contract to return the input content cast in to >> >> the same type as the Filter . Returning a null value indicates the >> filter does not match. >> >> >> >> public interface Filter extends >> >> java.io.Serializable >> { >> >> public T filter(Content content); >> >> } >> >> >> >> Here is the JDom1.1 interface: >> >> public interface Filter extends java.io.Serializable { >> >> public boolean matches(Object obj); >> >> } >> >> >> >> Significant implications of this change include the change of the >> >> method >> name from 'matches' to 'filter'. >> >> This is somewhat mitigated by the 'AbstractFilter' method 'matches' >> which is simply: >> >> return filter(content) != null; >> >> >> >> Another 'regression' is that the filter and matches method now require >> at least 'Content' instead of 'Object' data. >> >> A direct implication of this is that you can not have a Filter on >> Document Objects. I could not find any examples of >> >> this in the project, or my work environment. It seems to be somewhat >> 'safe'. This is especially true because Filters >> >> are primarily used as input to the Parent.getContent(Filter) method, >> which, since the content can never be Document, >> >> implies this change is probably benign. It does make some code >> >> redundant >> in class ContentFilter. >> >> >> >> All classes that implement Filter have been modified to be sensible. >> >> >> >> This is the change that makes the code: >> >> List kids = someelement.getChildren(); >> >> possible. >> >> >> >> >> >> 2. Modified Parent to be generic. >> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> >> >> This allows for the method: >> >> Parent addContent(Content content) >> >> to be added to the Parent interface, and still return the right >> >> type... >> >> >> >> >> >> 2. Rewrote much of ContentList (again) >> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> Three motivators for this change: >> >> a) Generics - so much had to change to accomodate Generics, seems >> >> this >> was the core impact. >> >> b) Compliance - set() method on Collections are not supposed to >> >> impact >> Concurrent Modification, >> >> but JDom did. Changed this so that set() does not impact >> >> concurrent >> status. >> >> c) Performance - modified FilterList and FilterListIterator to work >> >> on >> an as-needed basis. Will >> >> cache known content, but will only filter data on an as-needed >> basis, or 'lazy' basis. Need to >> >> devise tests to measure performance impact, but things like >> element.getChildren.iterator() will be >> >> much faster. >> >> >> >> Another motivator was conformance with existing concepts, specifically >> List.subList(int,int). The paradigm for >> >> SubList is that modifications to the base list would cause concurrent >> exception in subList. This seems to be >> >> appropriate for FilterLists too, but, too much code depends on >> essentially dynamic/concurrent modification >> >> to make the change. The old behaviour remains.... leading to >> >> potentially >> odd things in FilterList iterators. >> >> >> >> >> >> 3. Removed complexities in JDOMException >> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> In Java5 we have the initCause method embedded in to Throwable. We >> >> don't >> need to jump through hoops any more. >> >> >> >> >> >> 4. Removed TextBuffer class >> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> This was an attempt to be a better performing StringBuffer. With >> >> Java5's >> StringBuilder, we don't need to worry. >> >> >> >> >> >> 5. Created AttributeType Enum >> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> This makes new attributes easy to manage, and also eliminates a bunch >> >> of >> org.jdom.test.* stuff. >> >> This also has probably the largest impact on existing code because of >> the requriement to change things like >> >> Attribute att = new Attribute ("name", "somevalue", >> Attribute.ID_TYPE); >> >> to >> >> Attribute att = new Attribute ("name", "somevalue", >> AttributeType.ID_TYPE); >> >> >> >> On the other hand, it is all now TypeSafe ;-) >> >> >> >> >> >> 6. Created Annotation CVS_ID >> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> This is used instead of the static field CVS_ID. This is set up to be >> >> an >> annotation to a class. Previously we had: >> >> public class Attribute implements Serializable, Cloneable { >> >> private static final String CVS_ID = "@(#) $RCSfile: >> Attribute.java,v $ $Revision: 1.56 $ $Date: 2007/11/10 05:28:58 $ $Name: >> $"; >> >> .... >> >> >> >> we now instead have: >> >> @CVS_ID("@(#) $RCSfile: Attribute.java,v $ $Revision: 1.56 $ >> >> $Date: >> 2007/11/10 05:28:58 $ $Name: $") >> >> public class Attribute implements Serializable, Cloneable { >> >> >> >> The motivation for this is because Eclipse complains when there are >> unused private members... but, this is perfect >> >> fodder for annotations. >> >> >> >> As a result, all org.jdom.* classes in the main repo have been >> >> modified >> to use the annotation rather than the static String. >> >> >> >> As an excercies later, we will be able to programatically be able to >> determing all the CVS details at runtime using >> >> the annotations, and I have tested that >> >> >> >> >> >> 7. General Tidy-up. >> >> ^^^^^^^^^^^^^^^^^^^ >> >> >> >> Fixed all JavaDoc comments where applicable. Ensured @Override was >> specified where appropriate, etc. >> >> basically, I set strict rules in Eclipse, and then fixed all issues. >> >> >> >> >> >> 8. JavaDoc >> >> ^^^^^^^^^^ >> >> All public and protected classes, methods, and fields have had their >> JavaDoc entries inspected and completed. >> >> >> >> >> >> 9. build.xml >> >> ^^^^^^^^^^^^ >> >> >> >> set Java compliance levels, JDom version number. >> >> >> >> TESTS >> >> ===== >> >> org.jdom.test.* has been modified to use and test the new code >> >> properly. >> >> Alltests was modified to include some suites that were not included. >> >> Alltests has been run, and all run tests have passed. >> >> >> >> >> >> CONTRIB >> >> ======= >> >> All code has been modified to do what appears to be sane usage of the >> new JDom, but testing has not been done. >> >> >> >> STILL TO DO >> >> =========== >> >> >> >> FilterIterator seems clunky still. Especially the XXX warning. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 21/07/2011 7:19 PM, Rolf Lear wrote: >> >>> >> >>> I did a JDOM conversion a while back. Made the code available to >> >>> those >> who were interested. >> >>> >> >>> There are a few 'gotchas', and most of the Generics implementation >> relies on 'hiding' explicit casting inside of the ContentList class. >> >>> >> >>> It makes code that compiles against the JDOM cleaner, but does not >> actually improve any reliability... >> >>> >> >>> Additionally, the XPath support is pretty much impossible to >> accomplish. >> >>> >> >>> Let me dig up the code.... Or, rather, anyone interested should mail >> >>> me >> directly. >> >>> >> >>> Rolf >> >>> >> >> >> >> _______________________________________________ >> >> To control your jdom-interest membership: >> >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >> > >> > >> > _______________________________________________ >> > To control your jdom-interest membership: >> > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >> >> >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >> From jdom at tuis.net Mon Aug 8 06:12:26 2011 From: jdom at tuis.net (Rolf) Date: Mon, 08 Aug 2011 09:12:26 -0400 Subject: [jdom-interest] jdom 2.0 with generics In-Reply-To: <3b9934f544c3719131b24b4aa4e22408@tuis.net> References: <4E282315.1050701@peralex.com> <4E2832EE.7010209@uni-jena.de> <4E284487.7060602@jalios.com> <7371847E-4174-4356-82DA-205087597E92@activemath.org> <4E28B3F6.9080501@tuis.net> <4E28BC97.80402@tuis.net> <27527DC0-3636-427E-BB26-EDF42662523B@servlets.com> <3b9934f544c3719131b24b4aa4e22408@tuis.net> Message-ID: <7b96e04f1f42376ba621b5a0c7fc23e6@tuis.net> Hi Brad... again. I see also that Jason added the issue for Maven. https://github.com/hunterhacker/jdom/issues/3 There, it's now double-tracked. Also, I noted that my 'identity' on my web-based mail system has me down as 'jdom', so, hopefully I have fixed that, and I'm now 'Rolf'. Rolf On Mon, 08 Aug 2011 08:52:24 -0400, jdom wrote: > Hi Brad > > In the short term it is unlikely that the JDOM repo will be converted to a > maven-style build. I simply do not use maven at all, and I do not know the > maven 'paradigm'. > > I know that the possibility is there to produe the maven co-ordinates for > the JDOM releases, but it woul dmake sense to first get something usable > out of JDOM2 before we go publishing it as a maven resource. > > Bottom line is that, if it happens, it will be one of the last things to > go through. Probably only after the alpha/beta/final stages of JDOM2 are > settled. > > Still, JDOM is all about 'Java manipulation of XML made easy', so, it > should be considered, and I've updated the wiki page > https://github.com/hunterhacker/jdom/wiki/JDOM-2.0 to reflect that Maven > artifacts should be a possible goal of JDOM2. > > Pleased to see the mounting excitement for JDOM2. > > Rolf > From jdom at tuis.net Mon Aug 8 06:47:24 2011 From: jdom at tuis.net (Rolf) Date: Mon, 08 Aug 2011 09:47:24 -0400 Subject: [jdom-interest] JDOM2 Update Message-ID: Hi Everyone. Just to bring everyone up to date with JDOM2. The current plan is described on the wiki page: https://github.com/hunterhacker/jdom/wiki/JDOM-2.0 The initial steps are described as: 1. Migrate the code from CVS to GitHub (keeping all the history). 2. Create a branch for 2.0 3. Do the basic package renames. 4. Fix the test case that's currently failing (test_TCM__void_setExpandEntities_boolean) 5. Upgrade the JUnit libraries and tests 6. Use Cobertura to build up the JUnit test cases to get much better coverage of the junit tests on JDOM (currently have only got 40% coverage of the org.junit code from the JUnit test cases....). Fix any issues that arise in untested code. 7. Modify the core code and the test harness together to implement the changes - document what changes are made so that we can get a list of rules for migration from JDOM 1 to JDOM 2. 8. Confirm any deviations from 'compatibility' with the jdom-interest list to ensure that all changes are reasonable. 9. Complete the migration, ensure all JavaDoc is complete. All Tests are run, and code test coverage is 'complete'. The initial preparation steps (set up github, branches, basic package rename, etc.) are done. See JDOM's new home at https://github.com/hunterhacker/jdom What that means is that the current JDOM2 state is: JDOM2 looks exactly like JDOM, except it has a new package name, and all the JUnit tests now are based on JUnit 4.8.2. In order to have a clear and documented migration path from JDOM to JDOM2 we need to know and document all significant changes in the API. The most comprehensive way to do that is to ensure that the current JDOM is well covered with unit tests, and that as we perform the JDOM2 migration, we ensure that all unit tests pass, and if there are any reasons to change the API, the unit tests get modified to adapt, and the deviation is documented. In other words, in order to have the best possible JDOM2 it's important to ensure that JDOM itself is very well covered for regression tests. This is where JDOM2 is at the moment: building JUnit tests basically for JDOM 1.1.1 No work will be done on any 'generics' or other API modifications until the JUnit tests have adequate coverage for regression purposes. In order to track the progress of the regression testing, the tool 'Cobertura' is being used to track the JUnit code coverage, and there is an ant target 'coverage' that will do that for us. Currently the core JDOM code has about 40% coverage. This number should be better than 95% before any real 'fun' work can begin. My expectation is that the JUnit coverage will probably amount to about half of the real work of the JDOM2 process. In light of the above, this is also an invitation for assistance in doing the hard work of building the best and most comprehensive testing we can. Once that is done we can get on with the fun part of doing the actual migration (with the security of the unit tests to keep us on track). In order to set the expectations for JDOM2, I anticipate that any code submission should be accompanied with as comprehensive JUnit testing as possible. No changes will be accepted on existing code unless there are first JUnit tests for that code. No patches/pulls/commits will be allowed if they result in failing tests. In order to facilitate the patching/submission process I am happy to accept contributions in any reasonable format.... but, changes should be in as small a 'chunk' as reasonably possible though, in order to make merging and tracking as simple as possible. All changes will be attributed appropriately. If you intend to get busy writing JUnit test cases, please drop me a note so that I can co-ordinate with others writing tests so that there is no duplication of effort. If you have any comments, questions, suggestions, please speak up! Thanks all, happy coding. Rolf From jdom at tuis.net Mon Aug 8 07:12:53 2011 From: jdom at tuis.net (Rolf) Date: Mon, 08 Aug 2011 10:12:53 -0400 Subject: [jdom-interest] jdom 2.0 with generics In-Reply-To: <8BC54442-FD8F-4E8F-8FE9-47A62FB7DA33@hoplahup.net> References: <4E282315.1050701@peralex.com> <4E2832EE.7010209@uni-jena.de> <4E284487.7060602@jalios.com> <7371847E-4174-4356-82DA-205087597E92@activemath.org> <4E28B3F6.9080501@tuis.net> <4E28BC97.80402@tuis.net> <27527DC0-3636-427E-BB26-EDF42662523B@servlets.com> <3b9934f544c3719131b24b4aa4e22408@tuis.net> <8BC54442-FD8F-4E8F-8FE9-47A62FB7DA33@hoplahup.net> Message-ID: Hi Paul. Couple of things.... I've found that git's 'mv' tracking is somewhat problematic, it's not as easy to track an item's history than before the move.... you have to specify --follow for the 'git log' request. Neither eclipse nor github appear to apply the --follow logic to the moved files' history... It would be nicer if they did, since all the classes have moved once already (jdom -> jdom2). I acknowledge that the current system of dumping the supporting jars in the repo is 'crude', but, it has some other advantages. Having everyone using the same jar versions for the JDOM2 development would reduce the number of 'head-scratching' problems. This is up for discussion, but it seems that eliminating inconsistencies at this point in the development would be useful. Finally, I am in the habit of using ant and eclipse (call me 'old fashioned'), and I have the habit of throwing in an 'eclipse' target for ant build.xml files. I have added this target to the jdom build file. Running 'ant eclipse' and refreshing your eclipse project (f5) will set up/update your eclipse source folders, and library dependencies in a way that makes it all 'just work'. I normally have a 'smarter' eclipse target that uses the ant classpath to set up eclipse, but, in this case, I have it hard-coded at the moment. I see that it's missing the xml-apis.jar file, so it needs an update anyway. I'll make it dynamic based on the ant compile classpath instead. Obviously the demand for 'Mavenization' is growing... perhaps the most important question is 'how important' is it? I have always worked in an environment where build dependencies are more tightly controlled than what maven would allow, and the dependency-loading nature of maven would be 'wrong'. If you can make a convincing argument to 'Mavenize' then the actual commit process would have to be very tightly coordinated, and it would interrupt the actual JDOM2 coding as things stabilize. Further, it would also benefit from having the comprehensive unit testing in order to confirm that nothing has broken in 'the wash'. As for a full Maven re-structure, I am hesitant... and I think Jason will have to weigh in with the final word on that. It's more far-reaching than just JDOM2... Rolf On Mon, 8 Aug 2011 15:25:31 +0200, Paul Libbrecht wrote: > I think Brad's offer was to do it. > It does involve an amount of move around but it brings a few advantages > for people to take things up. > > Except for being able to transparently depend on jdom if it makes its way > into the maven repo (that's somewhat further), it allows to open in Eclipse > and IntelliJ IDEA directly, classpath and sourcepath all set. > > Brad, have you tried using the IntelliJ IDEA or Eclipse git checkout > methods (IntelliJ had me locate a Git executable which I had to download, > about 3 minutes)? If using this rearranging there will then nicely keep > history the same way an svn mv would do. > > paul > > Le 8 ao?t 2011 ? 14:52, jdom a ?crit : > >> >> Hi Brad >> >> In the short term it is unlikely that the JDOM repo will be converted to >> a >> maven-style build. I simply do not use maven at all, and I do not know >> the >> maven 'paradigm'. >> >> I know that the possibility is there to produe the maven co-ordinates for >> the JDOM releases, but it woul dmake sense to first get something usable >> out of JDOM2 before we go publishing it as a maven resource. >> >> Bottom line is that, if it happens, it will be one of the last things to >> go through. Probably only after the alpha/beta/final stages of JDOM2 are >> settled. >> >> Still, JDOM is all about 'Java manipulation of XML made easy', so, it >> should be considered, and I've updated the wiki page >> https://github.com/hunterhacker/jdom/wiki/JDOM-2.0 to reflect that Maven >> artifacts should be a possible goal of JDOM2. >> >> Pleased to see the mounting excitement for JDOM2. >> >> Rolf >> From bshuffman at gmail.com Tue Aug 9 18:01:34 2011 From: bshuffman at gmail.com (Bradley S. Huffman) Date: Tue, 9 Aug 2011 20:01:34 -0500 Subject: [jdom-interest] Parsing a MODS-document with validation fails In-Reply-To: <4E417F4D.8080006@algorithmics.com> References: <4E26D6E5.2010309@uni-jena.de> <4E417F4D.8080006@algorithmics.com> Message-ID: On Tue, Aug 9, 2011 at 1:41 PM, Rolf Lear wrote: > There are conditions where there is no prefix available for a default/fixed > attribute. Specifically, if an attribute is declared to be form="qualified", > and the Default namespace for the document is the targetNamespace for the > attribute.... and, the XML document does not have an explicitly prefixed > version of the default namespace as well, then there is no way to get the > namespace prefix. Wow, that was a mouthful. But the way I read section 6.2, attributes are never in the default namespace, either they are in a namespace and prefixed, or unprefixed and in no namespace. From thomas.scheffler at uni-jena.de Tue Aug 9 23:32:40 2011 From: thomas.scheffler at uni-jena.de (Thomas Scheffler) Date: Wed, 10 Aug 2011 08:32:40 +0200 Subject: [jdom-interest] Parsing a MODS-document with validation fails In-Reply-To: <38CA00BB-AFF4-4ED7-BAFE-D4465BADB6FD@servlets.com> References: <4E26D6E5.2010309@uni-jena.de> <4E417F4D.8080006@algorithmics.com> <38CA00BB-AFF4-4ED7-BAFE-D4465BADB6FD@servlets.com> Message-ID: <4E422608.6040705@uni-jena.de> Hi, sorry I am missing a mail from a list or something. I do not have the full code here for a proper review. But from the mail It seems as you are using tree traversal to get the correct namespace prefix. This looks a bit silly to me, as this can be a lot of work on large XML-files although it should work, too. Why do you not use my second patch with the startPrefixMapping() and endPrefixMapping()? For me it looks better to store this information in a proper place and throw it away after endPrefixMapping() event, than walking up the tree. But again, I am missing the code you both are talking about. regards, Thomas Am 10.08.2011 01:14, schrieb Jason Hunter: > // First look at the element itself > >> if (p.getNamespace().getURI().equals(attURI) >> && !overrides.contains(p.getNamespacePrefix()) >> && !"".equals(element.getNamespace().getPrefix())) { >> // we need a prefix. It's impossible to have a namespaced >> // attribute if there is no prefix for that attribute. >> attNS = p.getNamespace(); >> break uploop; >> } > > // Then any additional namespaces defined on the element > >> overrides.add(p.getNamespacePrefix()); >> for (Iterator it = p.getAdditionalNamespaces().iterator(); >> it.hasNext(); ) { >> Namespace ns = (Namespace)it.next(); >> if (!overrides.contains(ns.getPrefix()) >> && attURI.equals(ns.getURI())) { >> attNS = ns; >> break uploop; >> } >> overrides.add(ns.getPrefix()); >> } > > // If we haven't hit something yet, keep walking up the tree > >> if (p == element) { >> p = currentElement; >> } else { >> p = p.getParentElement(); >> } >> } while (p != null); From thomas.scheffler at uni-jena.de Wed Aug 10 00:37:19 2011 From: thomas.scheffler at uni-jena.de (Thomas Scheffler) Date: Wed, 10 Aug 2011 09:37:19 +0200 Subject: [jdom-interest] Parsing a MODS-document with validation fails In-Reply-To: <4E417F4D.8080006@algorithmics.com> References: <4E26D6E5.2010309@uni-jena.de> <4E417F4D.8080006@algorithmics.com> Message-ID: <4E42352F.30508@uni-jena.de> Hi, right after sending a mail that I did not receive this mail, I got it ;-) > I've put together a test case for this. See attached files. The XML and > XSD files go in junit-test/resources > The TestSAXComplicatedSchema.java goes in > junit-test/src/java/org/jdom/tes/cases/input > > Whatever fix we decide on can be run through this.... currently it just > reproduces the problem. > > The 'bonus' is that the XML/schema/imports are much simpler than the > MODS stuff. I was thinking of providing a test case, too. But currently I have have a lot on my ToDo list. Thanks for your work. > Thomas, I've looked at your latest patch, and I think it is too > heavy-weight... in the sense that it carries a lot of data through the > hierarchy... two maps, a list, it all seems like too much. I struggled > to follow some of the logic. I think there's a simpler option. You are right, it is extra work to maintain these structures for a case that no one hit before. One can find arguments for one or the other solution. The amount of addition memory should be negligible but my patch introduced a bit of work while parsing every document while you suggested changes seems to produce more work in the rare case that: 1. an attribute is present with a namespace and the QName does not have a prefix. 2. information on the prefix is held way up in the document hierarchy. > I fact, when I looked more closely, the data is all available. If you > encounter an attribute with the same qName and localname, but with a > URI, then hunt up the Element hierarchy for a prefixed declaration of > that namespace. You are right with that. The data should be there in most cases of this rare case. I found your code a bit hard to understand, especially your do-while with those override prefix checks. If we do not use the SAX events here, and there is a good documentation for that, and write code our own, it should be well understandable in a few years. Maybe I find the time in the following days to set up a benchmark on that to compare both solutions. And maybe those differences will complete any further discussion ;-) Until now I was using jdom as a library since it beta stages and I was quite impressed how quick I was able to understand the code and provide a fix. I think not every library out there is on that quality. This is something that had to be said. regards, Thomas From mike at saxonica.com Wed Aug 10 02:03:37 2011 From: mike at saxonica.com (Michael Kay) Date: Wed, 10 Aug 2011 10:03:37 +0100 Subject: [jdom-interest] Parsing a MODS-document with validation fails In-Reply-To: <4E42352F.30508@uni-jena.de> References: <4E26D6E5.2010309@uni-jena.de> <4E417F4D.8080006@algorithmics.com> <4E42352F.30508@uni-jena.de> Message-ID: <4E424969.5070908@saxonica.com> > You are right, it is extra work to maintain these structures for a > case that no one hit before. One can find arguments for one or the > other solution. The amount of addition memory should be negligible but > my patch introduced a bit of work while parsing every document while > you suggested changes seems to produce more work in the rare case that... Forgive me butting in to a thread that I've only been skim-reading until now. But I thought I would look at what Saxon does about this problem. Firstly, Saxon states in its documentation that it expects the stream of ContentHandler events to correspond to those that come from a parser that has been configured with namespaces="true" and namespace-prefixes="false". It has no way of checking this in general (though it does so on paths where it has access to the XMLReader). Saxon does a few checks on the consistency of the event stream where these can be done cheaply. For example, it checks for the attribute names "xmlns" and "xmlns:*" and ignores them if they appear, even though they shouldn't appear in theory. But there's one area Saxon relies on something that isn't guaranteed by the SAX spec, namely it assumes that the QName will be present and correct, even though it is optional when namespace-prefixes="false". I made this decision because all known XML parsers supply the QName, and because coping with its absence would incur significant cost on a performance-critical path. I've reasoned in the path that if someone needs to work with a source of SAX events that doesn't supply the QName, a filter could be added to the pipeline to make good the deficiency. In this particular case, if I've understood the thread correctly, the QName is present but doesn't contain a legitimate prefix. In Saxon (where I'm sure the same sequence of SAX events might be received) I think I would have similar problems in dealing with this input. My response to a bug report on this would be that the input is invalid according to the SAX spec and should be corrected by inserting a filter: there is an implicit constraint that the stream of SAX events represents a well-formed XML document, and in a well-formed XML document, if an attribute is in a namespace then it must have a prefix. I wouldn't be prepared to add a performance penalty into the mainstream document building path in order to detect or repair this rare anomaly. Michael Kay Saxonica From jdom at tuis.net Wed Aug 10 08:40:27 2011 From: jdom at tuis.net (Rolf Lear) Date: Wed, 10 Aug 2011 11:40:27 -0400 Subject: [jdom-interest] Parsing a MODS-document with validation fails In-Reply-To: <4E422608.6040705@uni-jena.de> References: <4E26D6E5.2010309@uni-jena.de> <4E417F4D.8080006@algorithmics.com> <38CA00BB-AFF4-4ED7-BAFE-D4465BADB6FD@servlets.com> <4E422608.6040705@uni-jena.de> Message-ID: <4E42A66B.9020705@tuis.net> Hi Thomas. I don't want you to think I just 'dismissed' your patch(es). I know you've replied to the other mail as well, but bear with me... This particular problem is/was very hard to understand the way it was first presented. The MODS Schema is 'not simple', the XML is complex, it's all just 'murky'. Further, given my poor understanding of the problem, it was even harder to understand your 'fix', especially since it involved 'maintaining' a set of new structures. I think that I, like I imagine most people who looked at the problem, quickly became overwhelmed by the sheer volume of XML and XMLSchema. Actually, I don't think many people actually had a look simply because, what's the expression... "TL;DR". My intention was not so much to 'fix' the problem, but to understand it. All I really did was 'create a simple testcase'.... Once I had the 'simple' test case, it sort of 'crystalized' for me, and I could understand your fix better. I had some concerns still, though. For example, at first I could not see how your patch was dealing with namespace prefixes being redeclared... ... then, when I figured it out, I looked at the nsURIMapping map, and I decided that it was buggy, in the sense that there can be multiple prefixes for a single URI, and that your patch only 'preserves' one (though I may be wrong). So, I understand now what your patch is doing... and, I figured that for an 'edge case', the code was duplicating a lot of effort that was already embedded in the Element hierarchy. Also, it is 'touching' a lot of code, and introduces a significant overhead in the 'normal' usage. I just figured that we could use the existing structures in the JDOM hierarchy better than having to re-invent all the Namspace tracking that needs to be done to 'do it right'. Finally, the 'value' of my submission is more in the actual test case which (at least for me) makes a complicated problem a little easier to understand and reproduce than the actual fix. This is the 'beauty' of open source, the sense that we can all look at the issue, and come up with a 'better' answer. I am sure (at least I hope) that a lot of people will carefully scrutinize whatever fix is finally applied. Rolf On 10/08/2011 2:32 AM, Thomas Scheffler wrote: > Hi, > > sorry I am missing a mail from a list or something. I do not have the > full code here for a proper review. But from the mail It seems as you > are using tree traversal to get the correct namespace prefix. This > looks a bit silly to me, as this can be a lot of work on large > XML-files although it should work, too. > > Why do you not use my second patch with the startPrefixMapping() and > endPrefixMapping()? For me it looks better to store this information > in a proper place and throw it away after endPrefixMapping() event, > than walking up the tree. > > But again, I am missing the code you both are talking about. > > regards, > > Thomas > > Am 10.08.2011 01:14, schrieb Jason Hunter: >> // First look at the element itself >> >>> if (p.getNamespace().getURI().equals(attURI) >>> && !overrides.contains(p.getNamespacePrefix()) >>> && !"".equals(element.getNamespace().getPrefix())) { >>> // we need a prefix. It's impossible to have a namespaced >>> // attribute if there is no prefix for that attribute. >>> attNS = p.getNamespace(); >>> break uploop; >>> } >> >> // Then any additional namespaces defined on the element >> >>> overrides.add(p.getNamespacePrefix()); >>> for (Iterator it = p.getAdditionalNamespaces().iterator(); >>> it.hasNext(); ) { >>> Namespace ns = (Namespace)it.next(); >>> if (!overrides.contains(ns.getPrefix()) >>> && attURI.equals(ns.getURI())) { >>> attNS = ns; >>> break uploop; >>> } >>> overrides.add(ns.getPrefix()); >>> } >> >> // If we haven't hit something yet, keep walking up the tree >> >>> if (p == element) { >>> p = currentElement; >>> } else { >>> p = p.getParentElement(); >>> } >>> } while (p != null); > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From bcox at virtualschool.edu Wed Aug 10 15:57:54 2011 From: bcox at virtualschool.edu (Brad Cox) Date: Wed, 10 Aug 2011 18:57:54 -0400 Subject: [jdom-interest] jdom 2.0 with generics In-Reply-To: References: <4E282315.1050701@peralex.com> <4E2832EE.7010209@uni-jena.de> <4E284487.7060602@jalios.com> <7371847E-4174-4356-82DA-205087597E92@activemath.org> <4E28B3F6.9080501@tuis.net> <4E28BC97.80402@tuis.net> <27527DC0-3636-427E-BB26-EDF42662523B@servlets.com> <3b9934f544c3719131b24b4aa4e22408@tuis.net> <8BC54442-FD8F-4E8F-8FE9-47A62FB7DA33@hoplahup.net> Message-ID: Glad to hear there's interest. Actually I've already done the work if it can be called that. There was nothing more to it than moving jdom-contrib, jdom-src and jdom-test into a common parent (jdom), moving src/* to src/main/java inside each, and writing four simple poms for each folder. Didn't chase any corner cases but the simple pom was all I needed to feel right at home. Absolutely right about maven as cross-IDE representation. I sincerely encourage using it. If I can help with the learning curve, just ask. Maven is simpler than it seems at first. Let me know if you want the changes. On Mon, Aug 8, 2011 at 12:23 PM, Joe Bowbeer wrote: > I've been switching over to maven for my cross-IDE projects recently, and > in fact was just converting some of mine from native NetBeans projects to > Maven projects -- which is the only cross-IDE project representation that > I'm aware of. (Maven projects are the easiest for everyone to consume, > assuming that everyone is using different IDEs or the command line.) > > That said, I build jdom extremely rarely, so I have no case of my own. > > On Mon, Aug 8, 2011 at 7:12 AM, Rolf wrote: > > >> Hi Paul. >> >> Couple of things.... I've found that git's 'mv' tracking is somewhat >> problematic, it's not as easy to track an item's history than before the >> move.... you have to specify --follow for the 'git log' request. >> >> Neither eclipse nor github appear to apply the --follow logic to the moved >> files' history... It would be nicer if they did, since all the classes >> have >> moved once already (jdom -> jdom2). >> >> I acknowledge that the current system of dumping the supporting jars in >> the repo is 'crude', but, it has some other advantages. Having everyone >> using the same jar versions for the JDOM2 development would reduce the >> number of 'head-scratching' problems. This is up for discussion, but it >> seems that eliminating inconsistencies at this point in the development >> would be useful. >> >> Finally, I am in the habit of using ant and eclipse (call me 'old >> fashioned'), and I have the habit of throwing in an 'eclipse' target for >> ant build.xml files. I have added this target to the jdom build file. >> >> Running 'ant eclipse' and refreshing your eclipse project (f5) will set >> up/update your eclipse source folders, and library dependencies in a way >> that makes it all 'just work'. >> >> I normally have a 'smarter' eclipse target that uses the ant classpath to >> set up eclipse, but, in this case, I have it hard-coded at the moment. I >> see that it's missing the xml-apis.jar file, so it needs an update anyway. >> I'll make it dynamic based on the ant compile classpath instead. >> >> Obviously the demand for 'Mavenization' is growing... perhaps the most >> important question is 'how important' is it? I have always worked in an >> environment where build dependencies are more tightly controlled than what >> maven would allow, and the dependency-loading nature of maven would be >> 'wrong'. >> >> If you can make a convincing argument to 'Mavenize' then the actual commit >> process would have to be very tightly coordinated, and it would interrupt >> the actual JDOM2 coding as things stabilize. Further, it would also >> benefit >> from having the comprehensive unit testing in order to confirm that >> nothing >> has broken in 'the wash'. >> >> As for a full Maven re-structure, I am hesitant... and I think Jason will >> have to weigh in with the final word on that. It's more far-reaching than >> just JDOM2... >> >> Rolf >> >> On Mon, 8 Aug 2011 15:25:31 +0200, Paul Libbrecht >> wrote: >> > I think Brad's offer was to do it. >> > It does involve an amount of move around but it brings a few advantages >> > for people to take things up. >> > >> > Except for being able to transparently depend on jdom if it makes its >> way >> > into the maven repo (that's somewhat further), it allows to open in >> Eclipse >> > and IntelliJ IDEA directly, classpath and sourcepath all set. >> > >> > Brad, have you tried using the IntelliJ IDEA or Eclipse git checkout >> > methods (IntelliJ had me locate a Git executable which I had to >> download, >> > about 3 minutes)? If using this rearranging there will then nicely keep >> > history the same way an svn mv would do. >> > >> > paul >> > >> > Le 8 ao?t 2011 ? 14:52, jdom a ?crit : >> > >> >> >> >> Hi Brad >> >> >> >> In the short term it is unlikely that the JDOM repo will be converted >> to >> >> a >> >> maven-style build. I simply do not use maven at all, and I do not know >> >> the >> >> maven 'paradigm'. >> >> >> >> I know that the possibility is there to produe the maven co-ordinates >> for >> >> the JDOM releases, but it woul dmake sense to first get something >> usable >> >> out of JDOM2 before we go publishing it as a maven resource. >> >> >> >> Bottom line is that, if it happens, it will be one of the last things >> to >> >> go through. Probably only after the alpha/beta/final stages of JDOM2 >> are >> >> settled. >> >> >> >> Still, JDOM is all about 'Java manipulation of XML made easy', so, it >> >> should be considered, and I've updated the wiki page >> >> https://github.com/hunterhacker/jdom/wiki/JDOM-2.0 to reflect that >> Maven >> >> artifacts should be a possible goal of JDOM2. >> >> >> >> Pleased to see the mounting excitement for JDOM2. >> >> >> >> Rolf >> >> >> >> > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > -- Cell: 703-594-1883 Blog: http://bradjcox.blogspot.com Web: http://virtualschool.edu Manassas VA 20111 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcox at virtualschool.edu Wed Aug 10 16:17:36 2011 From: bcox at virtualschool.edu (Brad Cox) Date: Wed, 10 Aug 2011 19:17:36 -0400 Subject: [jdom-interest] jdom 2.0 with generics In-Reply-To: References: <4E282315.1050701@peralex.com> <4E2832EE.7010209@uni-jena.de> <4E284487.7060602@jalios.com> <7371847E-4174-4356-82DA-205087597E92@activemath.org> <4E28B3F6.9080501@tuis.net> <4E28BC97.80402@tuis.net> <27527DC0-3636-427E-BB26-EDF42662523B@servlets.com> <3b9934f544c3719131b24b4aa4e22408@tuis.net> <8BC54442-FD8F-4E8F-8FE9-47A62FB7DA33@hoplahup.net> Message-ID: Re "IntelliJ IDEA or Eclipse git checkout methods", no I haven't tried them since mercurial does everything I need. Didn't want to tool up for jdom unless there's clear interest...and a recipe to follow so I don't screw something up. Re: "move-around", that can probably be minimized by dispensing with maven's src/main/java convention and just overriding that to use src in the pom. Might be useful to start that way to eliminate any impact at all on ant users. As I see it: negatives... none at all. Even putting the three parts in a common jdom parent isn't essential. The only delta is one new file, pom.xml, in each folder. Can be ignored if not desired. Positives: dependency management is all gain, no pain, compared to managing that lib folder with ant. When you're ready, jdom can be auto-distributed to maven repos where its automatically available to everyone. Being unable to manage jdom as I do everything else was the main reason i gave up on it earlier. The cross-IDE feature is really important too. I could go on. All gain no pain.... what more could you want? ;) On Wed, Aug 10, 2011 at 6:57 PM, Brad Cox wrote: > Glad to hear there's interest. Actually I've already done the work if it > can be called that. There was nothing more to it than moving jdom-contrib, > jdom-src and jdom-test into a common parent (jdom), moving src/* to > src/main/java inside each, and writing four simple poms for each folder. > Didn't chase any corner cases but the simple pom was all I needed to feel > right at home. > > Absolutely right about maven as cross-IDE representation. I sincerely > encourage using it. If I can help with the learning curve, just ask. Maven > is simpler than it seems at first. > > Let me know if you want the changes. > > On Mon, Aug 8, 2011 at 12:23 PM, Joe Bowbeer wrote: > >> I've been switching over to maven for my cross-IDE projects recently, and >> in fact was just converting some of mine from native NetBeans projects to >> Maven projects -- which is the only cross-IDE project representation that >> I'm aware of. (Maven projects are the easiest for everyone to consume, >> assuming that everyone is using different IDEs or the command line.) >> >> That said, I build jdom extremely rarely, so I have no case of my own. >> >> On Mon, Aug 8, 2011 at 7:12 AM, Rolf wrote: >> >> >>> Hi Paul. >>> >>> Couple of things.... I've found that git's 'mv' tracking is somewhat >>> problematic, it's not as easy to track an item's history than before the >>> move.... you have to specify --follow for the 'git log' request. >>> >>> Neither eclipse nor github appear to apply the --follow logic to the >>> moved >>> files' history... It would be nicer if they did, since all the classes >>> have >>> moved once already (jdom -> jdom2). >>> >>> I acknowledge that the current system of dumping the supporting jars in >>> the repo is 'crude', but, it has some other advantages. Having everyone >>> using the same jar versions for the JDOM2 development would reduce the >>> number of 'head-scratching' problems. This is up for discussion, but it >>> seems that eliminating inconsistencies at this point in the development >>> would be useful. >>> >>> Finally, I am in the habit of using ant and eclipse (call me 'old >>> fashioned'), and I have the habit of throwing in an 'eclipse' target for >>> ant build.xml files. I have added this target to the jdom build file. >>> >>> Running 'ant eclipse' and refreshing your eclipse project (f5) will set >>> up/update your eclipse source folders, and library dependencies in a way >>> that makes it all 'just work'. >>> >>> I normally have a 'smarter' eclipse target that uses the ant classpath to >>> set up eclipse, but, in this case, I have it hard-coded at the moment. I >>> see that it's missing the xml-apis.jar file, so it needs an update >>> anyway. >>> I'll make it dynamic based on the ant compile classpath instead. >>> >>> Obviously the demand for 'Mavenization' is growing... perhaps the most >>> important question is 'how important' is it? I have always worked in an >>> environment where build dependencies are more tightly controlled than >>> what >>> maven would allow, and the dependency-loading nature of maven would be >>> 'wrong'. >>> >>> If you can make a convincing argument to 'Mavenize' then the actual >>> commit >>> process would have to be very tightly coordinated, and it would interrupt >>> the actual JDOM2 coding as things stabilize. Further, it would also >>> benefit >>> from having the comprehensive unit testing in order to confirm that >>> nothing >>> has broken in 'the wash'. >>> >>> As for a full Maven re-structure, I am hesitant... and I think Jason will >>> have to weigh in with the final word on that. It's more far-reaching than >>> just JDOM2... >>> >>> Rolf >>> >>> On Mon, 8 Aug 2011 15:25:31 +0200, Paul Libbrecht >>> wrote: >>> > I think Brad's offer was to do it. >>> > It does involve an amount of move around but it brings a few advantages >>> > for people to take things up. >>> > >>> > Except for being able to transparently depend on jdom if it makes its >>> way >>> > into the maven repo (that's somewhat further), it allows to open in >>> Eclipse >>> > and IntelliJ IDEA directly, classpath and sourcepath all set. >>> > >>> > Brad, have you tried using the IntelliJ IDEA or Eclipse git checkout >>> > methods (IntelliJ had me locate a Git executable which I had to >>> download, >>> > about 3 minutes)? If using this rearranging there will then nicely keep >>> > history the same way an svn mv would do. >>> > >>> > paul >>> > >>> > Le 8 ao?t 2011 ? 14:52, jdom a ?crit : >>> > >>> >> >>> >> Hi Brad >>> >> >>> >> In the short term it is unlikely that the JDOM repo will be converted >>> to >>> >> a >>> >> maven-style build. I simply do not use maven at all, and I do not know >>> >> the >>> >> maven 'paradigm'. >>> >> >>> >> I know that the possibility is there to produe the maven co-ordinates >>> for >>> >> the JDOM releases, but it woul dmake sense to first get something >>> usable >>> >> out of JDOM2 before we go publishing it as a maven resource. >>> >> >>> >> Bottom line is that, if it happens, it will be one of the last things >>> to >>> >> go through. Probably only after the alpha/beta/final stages of JDOM2 >>> are >>> >> settled. >>> >> >>> >> Still, JDOM is all about 'Java manipulation of XML made easy', so, it >>> >> should be considered, and I've updated the wiki page >>> >> https://github.com/hunterhacker/jdom/wiki/JDOM-2.0 to reflect that >>> Maven >>> >> artifacts should be a possible goal of JDOM2. >>> >> >>> >> Pleased to see the mounting excitement for JDOM2. >>> >> >>> >> Rolf >>> >> >>> >>> >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >> > > > > -- > Cell: 703-594-1883 > Blog: http://bradjcox.blogspot.com > Web: http://virtualschool.edu > Manassas VA 20111 > > -- Cell: 703-594-1883 Blog: http://bradjcox.blogspot.com Web: http://virtualschool.edu Manassas VA 20111 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdom at tuis.net Wed Aug 10 19:19:07 2011 From: jdom at tuis.net (Rolf) Date: Wed, 10 Aug 2011 22:19:07 -0400 Subject: [jdom-interest] Parsing a MODS-document with validation fails In-Reply-To: <38CA00BB-AFF4-4ED7-BAFE-D4465BADB6FD@servlets.com> References: <4E26D6E5.2010309@uni-jena.de> <4E417F4D.8080006@algorithmics.com> <38CA00BB-AFF4-4ED7-BAFE-D4465BADB6FD@servlets.com> Message-ID: <4E433C1B.90903@tuis.net> Hi Jason, all. I've run through on the DOMBuilder side too. It is also a victim of this problem. In this case, the DOM model has is pretty much exactly what I expected to see given that it's built through the same xerces parser. Like the sax case, the DOM Attributes have the correct namespace declared, but they are all unprefixed. When processed through JDOM's DOMBuilder, these namespaces are all 'lost'. So, in effect, the DOMBuilder is going to need a 'matching' patch. Rolf On 09/08/2011 7:14 PM, Jason Hunter wrote: > I assume you mean line 568? > > I'll add some comments inline and you can tell me if I'm following the > logic right. > >> >> } else if (atts.getURI(i) != null && atts.getURI(i).length() > 0) { >> // the localname and qName are the same, but there is a >> // Namspace URI. We need to figure out the namespace prefix. >> // this is an unusual condition. Currently the only known trigger >> // is when there is a fixed/defaulted attribute from a validating >> // XMLSchema, and the attribute is in a different namespace >> // than the rest of the document, this happens whenever there >> // is an attribute definition that has form="qualified". >> // >> // or the schema sets attributeFormDefault="qualified" > > // The goal of this searching code is to find a good attNS namespace we > can use. > >> String attURI = atts.getURI(i); >> Namespace attNS = null; >> Element p = element; >> // We need to ensure that a particular prefix has not been >> // overridden at a lower level than what we are expecting. >> // track all prefixes to ensure they are not changed lower >> // down. >> HashSet overrides = new HashSet(); >> uploop: do { >> // Search up the Element tree looking for a prefixed namespace >> // matching our attURI > > // First look at the element itself > >> if (p.getNamespace().getURI().equals(attURI) >> && !overrides.contains(p.getNamespacePrefix()) >> && !"".equals(element.getNamespace().getPrefix())) { >> // we need a prefix. It's impossible to have a namespaced >> // attribute if there is no prefix for that attribute. >> attNS = p.getNamespace(); >> break uploop; >> } > > // Then any additional namespaces defined on the element > >> overrides.add(p.getNamespacePrefix()); >> for (Iterator it = p.getAdditionalNamespaces().iterator(); >> it.hasNext(); ) { >> Namespace ns = (Namespace)it.next(); >> if (!overrides.contains(ns.getPrefix()) >> && attURI.equals(ns.getURI())) { >> attNS = ns; >> break uploop; >> } >> overrides.add(ns.getPrefix()); >> } > > // If we haven't hit something yet, keep walking up the tree > >> if (p == element) { >> p = currentElement; >> } else { >> p = p.getParentElement(); >> } >> } while (p != null); > > // If we still don't have attNS we need to invent a unique one > >> if (attNS == null) { >> // we cannot find a 'prevailing' namespace that has a prefix >> // that is for this namespace. >> // This basically means that there's an XMLSchema, for the >> // DEFAULT namespace, and there's a defaulted/fixed >> // attribute definition in the XMLSchema that's targeted >> // for this namespace,... but, the user has either not >> // declared a prefixed version of the namespace, or has >> // re-declared the same prefix at a lower level with a >> // different namespace. >> // All of these things are possible. >> // Create some sort of default prefix. >> int cnt = 0; >> String base = "attns"; >> String pfx = base + cnt; >> while (overrides.contains(pfx)) { >> cnt++; >> pfx = base + cnt; >> } >> attNS = Namespace.getNamespace(pfx, attURI); >> } > > Finally build the attribute, using either a found attNS or an invented one > >> attribute = factory.attribute(attLocalName, atts.getValue(i), >> attType, attNS); >> } else { > > Lastly, DOMBuilder needs code like this too, no? > > -jh- > > > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From jhunter at servlets.com Wed Aug 10 22:37:07 2011 From: jhunter at servlets.com (Jason Hunter) Date: Wed, 10 Aug 2011 22:37:07 -0700 Subject: [jdom-interest] Parsing a MODS-document with validation fails In-Reply-To: <4E433C1B.90903@tuis.net> References: <4E26D6E5.2010309@uni-jena.de> <4E417F4D.8080006@algorithmics.com> <38CA00BB-AFF4-4ED7-BAFE-D4465BADB6FD@servlets.com> <4E433C1B.90903@tuis.net> Message-ID: Yes, that matches what I saw. If our setAttribute() didn't implicitly replace a pre-existing attribute of the same name, I expect we'd produce a malformed result like DOM. -jh- On Aug 10, 2011, at 7:19 PM, Rolf wrote: > Hi Jason, all. > > I've run through on the DOMBuilder side too. > > It is also a victim of this problem. In this case, the DOM model has is pretty much exactly what I expected to see given that it's built through the same xerces parser. Like the sax case, the DOM Attributes have the correct namespace declared, but they are all unprefixed. > > When processed through JDOM's DOMBuilder, these namespaces are all 'lost'. So, in effect, the DOMBuilder is going to need a 'matching' patch. > > Rolf > > On 09/08/2011 7:14 PM, Jason Hunter wrote: >> I assume you mean line 568? >> >> I'll add some comments inline and you can tell me if I'm following the >> logic right. >> >>> >>> } else if (atts.getURI(i) != null && atts.getURI(i).length() > 0) { >>> // the localname and qName are the same, but there is a >>> // Namspace URI. We need to figure out the namespace prefix. >>> // this is an unusual condition. Currently the only known trigger >>> // is when there is a fixed/defaulted attribute from a validating >>> // XMLSchema, and the attribute is in a different namespace >>> // than the rest of the document, this happens whenever there >>> // is an attribute definition that has form="qualified". >>> // >>> // or the schema sets attributeFormDefault="qualified" >> >> // The goal of this searching code is to find a good attNS namespace we >> can use. >> >>> String attURI = atts.getURI(i); >>> Namespace attNS = null; >>> Element p = element; >>> // We need to ensure that a particular prefix has not been >>> // overridden at a lower level than what we are expecting. >>> // track all prefixes to ensure they are not changed lower >>> // down. >>> HashSet overrides = new HashSet(); >>> uploop: do { >>> // Search up the Element tree looking for a prefixed namespace >>> // matching our attURI >> >> // First look at the element itself >> >>> if (p.getNamespace().getURI().equals(attURI) >>> && !overrides.contains(p.getNamespacePrefix()) >>> && !"".equals(element.getNamespace().getPrefix())) { >>> // we need a prefix. It's impossible to have a namespaced >>> // attribute if there is no prefix for that attribute. >>> attNS = p.getNamespace(); >>> break uploop; >>> } >> >> // Then any additional namespaces defined on the element >> >>> overrides.add(p.getNamespacePrefix()); >>> for (Iterator it = p.getAdditionalNamespaces().iterator(); >>> it.hasNext(); ) { >>> Namespace ns = (Namespace)it.next(); >>> if (!overrides.contains(ns.getPrefix()) >>> && attURI.equals(ns.getURI())) { >>> attNS = ns; >>> break uploop; >>> } >>> overrides.add(ns.getPrefix()); >>> } >> >> // If we haven't hit something yet, keep walking up the tree >> >>> if (p == element) { >>> p = currentElement; >>> } else { >>> p = p.getParentElement(); >>> } >>> } while (p != null); >> >> // If we still don't have attNS we need to invent a unique one >> >>> if (attNS == null) { >>> // we cannot find a 'prevailing' namespace that has a prefix >>> // that is for this namespace. >>> // This basically means that there's an XMLSchema, for the >>> // DEFAULT namespace, and there's a defaulted/fixed >>> // attribute definition in the XMLSchema that's targeted >>> // for this namespace,... but, the user has either not >>> // declared a prefixed version of the namespace, or has >>> // re-declared the same prefix at a lower level with a >>> // different namespace. >>> // All of these things are possible. >>> // Create some sort of default prefix. >>> int cnt = 0; >>> String base = "attns"; >>> String pfx = base + cnt; >>> while (overrides.contains(pfx)) { >>> cnt++; >>> pfx = base + cnt; >>> } >>> attNS = Namespace.getNamespace(pfx, attURI); >>> } >> >> Finally build the attribute, using either a found attNS or an invented one >> >>> attribute = factory.attribute(attLocalName, atts.getValue(i), >>> attType, attNS); >>> } else { >> >> Lastly, DOMBuilder needs code like this too, no? >> >> -jh- >> >> >> >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From noel at peralex.com Thu Aug 11 06:22:55 2011 From: noel at peralex.com (Noel Grandin) Date: Thu, 11 Aug 2011 15:22:55 +0200 Subject: [jdom-interest] JDOM2 Update In-Reply-To: References: Message-ID: <4E43D7AF.9060803@peralex.com> Rolf wrote: > In order to have a clear and documented migration path from JDOM to JDOM2 > we need to know and document all significant changes in the API. There is no need to keep track of this. There are various tools for generating an API diff between 2 versions of a software component. > No work will be done on any 'generics' or other API modifications until > the JUnit tests have adequate coverage for regression purposes. That's a fine way to discourage interest. Most people don't like writing tests at best. Making us write tests for someone else's 3-year old code is just going to stifle contributions. Disclaimer: http://www.peralex.com/disclaimer.html From jdom at tuis.net Thu Aug 11 07:58:49 2011 From: jdom at tuis.net (Rolf Lear) Date: Thu, 11 Aug 2011 10:58:49 -0400 Subject: [jdom-interest] JDOM2 Update In-Reply-To: <4E43D7AF.9060803@peralex.com> References: <4E43D7AF.9060803@peralex.com> Message-ID: <957cac5043735db086ce4ce26e18403e@tuis.net> hi Noel. brace yourself, a long mail... ;-) On Thu, 11 Aug 2011 15:22:55 +0200, Noel Grandin wrote: > Rolf wrote: >> In order to have a clear and documented migration path from JDOM to JDOM2 >> we need to know and document all significant changes in the API. > There is no need to keep track of this. There are various tools for > generating an API diff between 2 versions of a > software component. 'There is no need to keep track...' is a fairly strong statement. Having a 'reference' of the differences between JDOM and JDOM2 will be useful for a number of reasons: 1. it indicates what motivation there could be to migrate 2. it indicates what challenges will be involved in the migration 3. it indicates that each 'deviation' has been carefully considered. JDOM's stability is 'legendary', and is a 'feature'. This sort of reference would give 'credibility' to JDOM2. How the document is made is less significant, but, if each change actually *is* carefully considered, then documenting it on the way should be trivial. I know that where I work a clear outline of what the changes/features in JDOM2 are will make the difference between a migration project happening or not. As for the tools available, I am interested to hear more about those. I've never investigated such things. Do you have recommendations? If nothing else, it would be really interesting to verify/reconcile any manually prepared document with a tool's results. I wonder if there are tools smart enough to pick up that Element.addContent(null) is going to now throw NullPointerException instead of IllegalArgumentException for example. >> No work will be done on any 'generics' or other API modifications until >> the JUnit tests have adequate coverage for regression purposes. > That's a fine way to discourage interest. Most people don't like writing > tests at best. > Making us write tests for someone else's 3-year old code is just going to > stifle contributions. > Perhaps you are right about stifling contributions, but if I could counter your statements with: 1. the code is far older than 3 years! 2. the tests will have to be written at some point.... why not before? ... or are you suggesting that the code should be untested? In theory, the JDOM2 migration should change the tests very little. 3. writing tests for the code you are about to change makes you understand the code you are going to change a whole lot better, and your changes will be a better quality. Think of it like a 'reminder', or 'warmup' of what you need to know to get it right. 4. people who are willing to put in the hardest work should be first in line to be doing 'the fun stuff'. Put it another way, the people who care enough to do the hard work are more likely to care about the final outcome. 5. the quality of JDOM2 will be directly related to the knowledge, familiarity, and commitment of the contributors. I can't name a single person who is 'intimately' familiar with JDOM's code. Even those people who initially wrote it (apologies Jason, Elliotte, Brad, Brett, Laurent, Victor, etc.) have to dust off the cobwebs of their memory banks before they can (re-)understand the more intimate nuances of the code. The people who write the JDOM tests will become the de-facto "experts". 6. as people go through the code writing the tests they will get ideas about how things can be 'fixed' with Java5 concepts. These can all lead to planning/discussing/'kicking' ideas before we actually write the changes. All these ideas can be tracked on github, and the merits of conflicting ideas can be thrashed out better than a simple 'ad-hoc' migration. People who are familiar with the actual code (not just the concepts) will have different opinions, valuable opinions. 7. this is an opportunity to become a key player in a respected tool where your actual knowledge of JDOM can be learned 'on the job'. You could be the one to bring JDOM back to the forefront of Java/XML libraries that works well with Generics (none of the other libraries does anything resembling a good job in this respect). I think there is this idea that 'making JDOM2 generified is easy'. I have done it once, and then recently I did it again, and came up with completely different ideas (partly due to having 3 more experience with generics, partly due to having a looser concept of compatibility). What I learned from that is that there is definitely more than one way to do it. We need 'qualified' people to make the decisions as to which mechanisms are good, will work, are best etc. JDOM2 is more than just a chance to make it 'Generic'. It is an opportunity 'fix' issues that affect the API, to introduce new concepts to the API (XPath on each node like XOM?), etc. Also, JDOM2 will be an opportunity of 'rapid development' (all things being relative), where things that are not normally considered for JDOM (like performance fixes, etc.) will be proposed, applied, etc. All those idea's you've had are now fair game for discussion. It has taken (by my count) 7 years to get from the point from the first interest in Java5 compatibility, to actually getting something happening. http://markmail.org/message/glxnqjcqkgi5mvpg Doing it right is more important than doing it fast. I have done it 'fast' once, and there are a lot of 'decisions' I made that need review, discussion, alternatives, etc. If you can be swayed by 'anecdotal' stuff, I am currently building testcases for the code, and am running in to a lot of issues. Things that the current testing of JDOM have not revealed, but my new tests have are. Is it better to migrate a 'clean' code base, or would you rather migrate the issues, and then fix the JDOM2 code? Also, for example, the current 'MODS'/fixed/default issue has required me to build test cases just to understand the existing code, to see why it has the funny nuances it does, and how something solves/fixes a problem. If those test cases had already existed then it would have been a lot quicker for someone to respond to the initial issue. Finally, having a plan is always better than having no plan. Having a plan where the incentive and reward is at the end is a better plan. If you can justify a better plan I am all ears. If you are suspicious about whether there are people out there who will still be encouraged to contribute, I have a lot of hope. For a start, there's me. If there's one person then there will probably be more. Also, if no-one steps up, it will just take longer to get the tests done. I am working through them, but I/we *will* get there. Then, if people want to hop on the band wagon when the tests are built to work on the fun stuff, then they'll be welcome too, but hopefully by then the big ideas will have already been discussed, and some of the bigger decisions already made, etc. At that point it should all be about implementing a new 'sub-plan' of what JDOM2 should look like, and that sub-plan will have been fleshed out while people get up-to-speed on the code. Anyway, enough rambling. If I gave the impression that I am hoping for dedicated, committed people to help on the JDOM2 migration, then, actually, that's a good thing, right? Rolf From noel at peralex.com Fri Aug 12 02:22:04 2011 From: noel at peralex.com (Noel Grandin) Date: Fri, 12 Aug 2011 11:22:04 +0200 Subject: [jdom-interest] JDOM2 Update In-Reply-To: <957cac5043735db086ce4ce26e18403e@tuis.net> References: <4E43D7AF.9060803@peralex.com> <957cac5043735db086ce4ce26e18403e@tuis.net> Message-ID: <4E44F0BC.5000201@peralex.com> Hi I respect and understand your desire to build a quality project. But... I, for one, was keen to help out, but I've wasted a lot of time trying to contribute to open-source projects only to have my contributions rejected or ignored because they were not __exactly__ the way the maintainer wanted. If you're that way inclined, that's fine, but then you're going to be doing the bulk of the work yourself. It's like good software - good software has a growth path to move from beginner level to expert. If there is no growth path with JDOM2, then I see no point in trying to contribute. Regards, Noel. Rolf Lear wrote: > hi Noel. > > brace yourself, a long mail... ;-) > > Disclaimer: http://www.peralex.com/disclaimer.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From burnside at kattare.com Fri Aug 12 15:12:21 2011 From: burnside at kattare.com (Ethan Burnside) Date: Fri, 12 Aug 2011 15:12:21 -0700 Subject: [jdom-interest] testing the list, please ignore Message-ID: <4E45A545.40309@kattare.com> Hi all, We're moving the list from one server to another... this is a test. Cheers, ~Ethan B. test 1 -- -------------------------------------------------- Ethan Burnside - President, Kattare I/S Email: burnside at kattare.com Web: http://www.kattare.com Phone: 1.877.KATTARE FAQ: http://www.kattare.com/docs/faq_browse.kvws -------------------------------------------------- From bshuffman at gmail.com Fri Aug 12 15:51:21 2011 From: bshuffman at gmail.com (Bradley S. Huffman) Date: Fri, 12 Aug 2011 17:51:21 -0500 Subject: [jdom-interest] Parsing a MODS-document with validation fails In-Reply-To: <4E42E6C0.40704@tuis.net> References: <4E26D6E5.2010309@uni-jena.de> <4E417F4D.8080006@algorithmics.com> <4E42352F.30508@uni-jena.de> <4E424969.5070908@saxonica.com> <4E42B30D.1040401@tuis.net> <4E42BDF0.5050606@saxonica.com> <4E42E6C0.40704@tuis.net> Message-ID: However JDOM, or any other project can't and shouldn't be adding kludges because another group won't fix there code and keeps 'passing the buck'. Therefore, I support Michael's suggestion of handling it with a filter or wrapper, but I do not support changing SAXHandler in any way. On Wed, Aug 10, 2011 at 3:14 PM, Rolf Lear wrote: > That issue is marked "Won't fix", with the comment: I agree it's a bug, but > it's not that easy to fix. The problem is what prefix?to use for the new > attribute. I'll think about it more. From jdom at tuis.net Sat Aug 13 14:14:18 2011 From: jdom at tuis.net (Rolf Lear) Date: Sat, 13 Aug 2011 17:14:18 -0400 Subject: [jdom-interest] Parsing a MODS-document with validation fails In-Reply-To: <4E46AB38.2010403@algorithmics.com> References: <4E46AB38.2010403@algorithmics.com> Message-ID: <4E46E92A.30405@tuis.net> Hi Brad. In this case I think the issue is too 'grey' to squarely lay the blame on any particular component. The use-case is such that it relies on a number of different shortcomings in a number of tools, including JDOM. Although the 'test cases' I put together illustrates the underlying problem (that there's no namespace prefix given to attributes that are 'sourced' from the XSD), the initial symptom as reported by Thomas is/was that JDOM was overwriting the value of his 'type' attribute with the value of the 'type' attrribute in the xlink namespace. In other words, if there is no change made to SAXHandler, then we make a 'broken' situation even worse. Saying "when XMLSchema specification is revised, and all the parsers do the 'right thing' we will give the right result" feels a little cheap. At a minimum, the SAXHandler has to be able to identify attributes that are in a namespace, but without a prefix, and then to ignore *that* attribute instead of potentially corrupting a different attribute. On the other hand, the fix/workaround for the problem is relatively trivial, easy to confine to just the scope of the issue, and it is safe for when we do (eventually) have parsers that provide a correct (or generated) prefix. The concept of the user having to apply a filter or wrapper to get sensible results is not pretty. One other thought, in order to get to this state, you have to declare your Parser to be namespace-aware... and then, after asking for the namspaces JDOM then does its processing based on the prefix, not the namespace... Rolf On Fri, 12 Aug 2011 17:51:21 Bradley S. Huffman wrote > However JDOM, or any other project can't and shouldn't be adding > kludges because another group won't fix there code and keeps 'passing > the buck'. Therefore, I support Michael's suggestion of handling it > with a filter or wrapper, but I do not support changing SAXHandler in > any way. > > On Wed, Aug 10, 2011 at 3:14 PM, Rolf Lear wrote: > > > That issue is marked "Won't fix", with the comment: I agree it's a bug, but > > it's not that easy to fix. The problem is what prefix to use for the new > > attribute. I'll think about it more. > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > ------------------------------------------------------------------------ > This email and any files transmitted with it are confidential and > proprietary to Algorithmics Incorporated and its affiliates > ("Algorithmics"). If received in error, use is prohibited. Please > destroy, and notify sender. Sender does not waive confidentiality or > privilege. Internet communications cannot be guaranteed to be timely, > secure, error or virus-free. Algorithmics does not accept liability > for any errors or omissions. Any commitment intended to bind > Algorithmics must be reduced to writing and signed by an authorized > signatory. > ------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.scheffler at uni-jena.de Mon Aug 15 00:52:17 2011 From: thomas.scheffler at uni-jena.de (Thomas Scheffler) Date: Mon, 15 Aug 2011 09:52:17 +0200 Subject: [jdom-interest] Parsing a MODS-document with validation fails In-Reply-To: <87379BB1-C561-4564-B12E-A57BD7FCB864@servlets.com> References: <4E46AB38.2010403@algorithmics.com> <4E46E92A.30405@tuis.net> <87379BB1-C561-4564-B12E-A57BD7FCB864@servlets.com> Message-ID: <4E48D031.5020207@uni-jena.de> Am 14.08.2011 07:15, schrieb Jason Hunter: > I agree with Rolf's assessment. I too. It is important what comes out at the end. If the input is valid, than the output should be valid, too. Blaming the user for not providing a custom filter working around a erroneous specification, would not help the user and not help the JDOM project, as traffic on the mailing list will be higher. Hope to see 1.1.2. soon. regards, Thomas > On Aug 13, 2011, at 2:14 PM, Rolf Lear wrote: > >> Hi Brad. >> >> In this case I think the issue is too 'grey' to squarely lay the blame >> on any particular component. The use-case is such that it relies on a >> number of different shortcomings in a number of tools, including JDOM. >> >> Although the 'test cases' I put together illustrates the underlying >> problem (that there's no namespace prefix given to attributes that are >> 'sourced' from the XSD), the initial symptom as reported by Thomas >> is/was that JDOM was overwriting the value of his 'type' attribute >> with the value of the 'type' attrribute in the xlink namespace. >> >> In other words, if there is no change made to SAXHandler, then we make >> a 'broken' situation even worse. Saying "when XMLSchema specification >> is revised, and all the parsers do the 'right thing' we will give the >> right result" feels a little cheap. >> >> At a minimum, the SAXHandler has to be able to identify attributes >> that are in a namespace, but without a prefix, and then to ignore >> *that* attribute instead of potentially corrupting a different attribute. >> >> On the other hand, the fix/workaround for the problem is relatively >> trivial, easy to confine to just the scope of the issue, and it is >> safe for when we do (eventually) have parsers that provide a correct >> (or generated) prefix. >> >> The concept of the user having to apply a filter or wrapper to get >> sensible results is not pretty. >> >> One other thought, in order to get to this state, you have to declare >> your Parser to be namespace-aware... and then, after asking for the >> namspaces JDOM then does its processing based on the prefix, not the >> namespace... >> >> Rolf >> >> On Fri, 12 Aug 2011 17:51:21 Bradley S. Huffman wrote >> >>> However JDOM, or any other project can't and shouldn't be adding >>> kludges because another group won't fix there code and keeps 'passing >>> the buck'. Therefore, I support Michael's suggestion of handling it >>> with a filter or wrapper, but I do not support changing SAXHandler in >>> any way. >>> >>> On Wed, Aug 10, 2011 at 3:14 PM, Rolf Lear wrote: >>> >>> > That issue is marked "Won't fix", with the comment: I agree it's a bug, but >>> > it's not that easy to fix. The problem is what prefix to use for the new >>> > attribute. I'll think about it more. From jdom at tuis.net Thu Aug 25 11:50:12 2011 From: jdom at tuis.net (Rolf Lear) Date: Thu, 25 Aug 2011 14:50:12 -0400 Subject: [jdom-interest] =?utf-8?q?Preparing_JDOM_1=2E1=2E2_=3F?= Message-ID: <2b5387045b45787a1ae51a31006c370f@tuis.net> Hi all Jason, the way I understand it is that we are intending a 1.1.2 release. There are some issues in GitHub targeting that release. I think it is worth discussing some fixes for a JDOM 1.1.2 release. Currently the list of 1.1.2 Milestone issues is: #1 Namespace for default attributes from XMLSchema https://github.com/hunterhacker/jdom/issues/1 #3 Should have a build in Maven Central https://github.com/hunterhacker/jdom/issues/3 I am unsure of how much priority should be put on 1.1.2 items. On the one hand, I think that these issues are high priority, and should be addressed. On the other hand, I find it hard to figure out where to draw the line. Also, the Maven issue is probably quite disruptive in terms of code impact.... and, I feel it would be a lot of effort to 'mavenize' both 1.1.2 and 2.0... I see that issue (#3) as being a 2.0 milestone, not 1.1.2 There are some other issues already filed which could be part of 1.1.2, but no-one has properly addressed. Things like https://github.com/hunterhacker/jdom/issues/9 - BaseURI not output. Also, what I am finding is that as I go through adding JUnit tests I have encountered a number of small issues. Each of them is trivial to fix (so far, anyway), but, when taken together, there are enough to warrant a 1.1.2 release. Further, I am sure that there will be even more as I cover more of the JDOM code. I have been itemizing these small issues in GitHub as I go so that I can 'document' what has changed, but the same items can be used to fix 1.1.2. I have been concentrating on the JDOM2 coverage, but, I think it would make sense to also get a 1.1.2 branch going, and clearing up some of the 1.1.2 issues. That is, assuming we are planning a 1.1.2 release.... we are, aren't we? I have inspected the branch on GitHub labeled as JDOM-1.1.1. There is one difference between that branch, and the actual code released as 1.1.1, and that is commit https://github.com/hunterhacker/jdom/commit/ea30b1e2b614f4b7d49de8a95af71fe3fb52ae2b It seems to me that I can move the 1.1.1 branch back up one commit, and then branch the 1.1.2 from where the 1.1.1 was. it seems simple in my head, but I will have to research the best way to do it in my head. Once we get a 1.1.2 branch going it should be easy for me to apply any fixes to both 2.0 and 1.1.2 (if we agree that they should be back-ported to 1.1.2). Anyway, the way I see it is that a 1.1.2 release should be 'planned' ( - or completely dismissed and just roll things in to 2.0.0). Am I missing something? Rolf P.S. it would also be nice to see whether jdom-interest is still working ... ;-) From elharo at ibiblio.org Thu Aug 25 18:54:22 2011 From: elharo at ibiblio.org (Elliotte Rusty Harold) Date: Thu, 25 Aug 2011 21:54:22 -0400 Subject: [jdom-interest] Preparing JDOM 1.1.2 ? In-Reply-To: <2b5387045b45787a1ae51a31006c370f@tuis.net> References: <2b5387045b45787a1ae51a31006c370f@tuis.net> Message-ID: I don't have a github account but something is off here, and it may not be JDOM. Jason says: "I did a simple test and printed out what was being given to SAXHandler by the parser. Sure enough, on this document when validation is turn on, the SAX parser is reporting two attributes with the same qname (which happens to be the local name since they are both unprefix), but in different namespaces." That should *NOT* be happening. There is no such thing as an unprefixed attribute that is in a namespace. That simply does not exist in XML. If the parser is reporting such an attribute, the parser is *wrong*. If XML Schema can define an unprefixed attribute in a namespace, then XML Schema is *wrong*. -- Elliotte Rusty Harold elharo at ibiblio.org From jdom at tuis.net Thu Aug 25 20:24:11 2011 From: jdom at tuis.net (Rolf Lear) Date: Thu, 25 Aug 2011 23:24:11 -0400 Subject: [jdom-interest] Preparing JDOM 1.1.2 ? In-Reply-To: References: <2b5387045b45787a1ae51a31006c370f@tuis.net> Message-ID: <4E5711DB.1030403@tuis.net> On 25/08/2011 9:54 PM, Elliotte Rusty Harold wrote: > I don't have a github account but something is off here, and it may > not be JDOM. Jason says: > > "I did a simple test and printed out what was being given to SAXHandler > by the parser. Sure enough, on this document when validation is turn > on, the SAX parser is reporting two attributes with the same qname > (which happens to be the local name since they are both unprefix), but > in different namespaces." > > That should *NOT* be happening. There is no such thing as an > unprefixed attribute that is in a namespace. That simply does not > exist in XML. If the parser is reporting such an attribute, the parser > is *wrong*. If XML Schema can define an unprefixed attribute in a > namespace, then XML Schema is *wrong*. > Hi Elliotte I think everyone is in violent agreement here... it sucks, and it's 'wrong'. XMLSchema should make it clear what should happen in this case, but XSD 1.0 is 'clear' that it should do nothing, and XSD 1.1 has partial coverage of the issue... (or, if you interpret it in just the right way, it does cover it, and say the prefix should be generated by the parser). Xerces (the parser) currently takes the XSD1.0 view, and claims that it's 'right' to not be prefixing the attributes. JDOM is the victim (other than the end user like Thomas) because it is getting bad information, and then doing worse things with it. Michael filed a 'ticket' against XMLSchema (1.1) to clarify/resolve it. You can see the discussion at: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13750 I filed a ticket against xerces at: https://issues.apache.org/jira/browse/XERCESJ-1524 Then there is the JDOM issue at: https://github.com/hunterhacker/jdom/issues/1 ahh, you found it. Rolf From jdom at tuis.net Mon Aug 29 07:58:49 2011 From: jdom at tuis.net (Rolf Lear) Date: Mon, 29 Aug 2011 10:58:49 -0400 Subject: [jdom-interest] Entity Resolver Cache/Catalog Message-ID: Hi all. As I am going through the junit tests, I am now at the point of testing the SAX and DOM builders. The issue I am having is that I am doing a lot of my work on the train as I commute.... and I don't have a network connection. This is a problem because the validating parsers need to get some DTD's and XML Schemas from the web... (if they are web-referenced resources). This is an age-old problem, but I can't think of a great solution. The ideal would be to run junit tests without having to have a network connection at all. Of course, I could just use input documents that only reference local resources... (and I have) but, in the spirit of JDOM, is there an option for making this process easy in a general sense? This is further compounded by there being some restrictions on some documents too, like the w3.org 'ban' on default Java user-agents: http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic/ My experimentation indicates that w3.org has put a blanket 'tarpit' of 30 seconds on any connection, regardless of what User-agent you use. This is 'significant'. Typical solutions to this problem are things like OASIS catalogs, etc. but that feels heavy-weight... or, is it? So, what options are there? Any ideas? I think the following are key issues (and OASIS does not solve them all): * access to local copies of unavailable resources (no network connection?). * general performance improvements by caching entities that have an appropriate 'expires' timeout... no network access for 'cached' resources. * improved 'internet-friendliness' reducing unnecessary bandwidth to places like w3.org * reduce the amount of 'expertise' a JDOM user needs to do 'the right thing'. Can JDOM be easily configured to become a good netizen? Should it be done by default? You can comment on the issue I raised as well at: https://github.com/hunterhacker/jdom/issues/26 Additionally, I'll summarize/copy discussion here on to that issue tracker as well. Rolf From paul at activemath.org Mon Aug 29 08:15:25 2011 From: paul at activemath.org (Paul Libbrecht) Date: Mon, 29 Aug 2011 17:15:25 +0200 Subject: [jdom-interest] Entity Resolver Cache/Catalog In-Reply-To: References: Message-ID: Le 29 ao?t 2011 ? 16:58, Rolf Lear a ?crit : > This is further compounded by there being some restrictions on some > documents too, like the w3.org 'ban' on default Java user-agents: > http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic/ > > My experimentation indicates that w3.org has put a blanket 'tarpit' of 30 > seconds on any connection, regardless of what User-agent you use. This is > 'significant'. Definitely, W3C wants you to stop reference DTDs by their URL-URIs. Well... it wants the parsers to stop keep parsing them. > Typical solutions to this problem are things like OASIS catalogs, etc. but > that feels heavy-weight... or, is it? I believe it was not very hard to configure the java-shipped Xerces with catalogs. And I would encourage the JDOM code to encourage this by showing good practice. Here's what I used before SAXparsing: > SAXParserFactory factory = SAXParserFactory.newInstance(); > System.setProperty("com.sun.org.apache.xerces.xni.parser.XMLParserConfiguration", > "com.sun.org.apache.xerces.parsers.XMLGrammarCachingConfiguration"); > SAXParser parser = factory.newSAXParser(); > > XMLCatalogResolver resolver = new XMLCatalogResolver(); > resolver.setPreferPublic(true); > resolver.setCatalogList(new String[]{this.getClass().getResource("xmlCatalog.xml").toExternalForm()}); > handler = new EventDeserializerSAXHandler(resolver); > if(LOG.isDebugEnabled()) LOG.debug("Starting parser."); > parser.parse(inputStream, handler); Caching, however, is for free with a single system-property (within the vm lifecycle) if I remember well. It would be cool to have SAXBuilder.setCatalog to make JDOM a good citizen! (or even better: SAXBuilder.addCatalogEntry(public, URL) with a javadoc example where the URL is using class.getResource(). paul also often developing in train ;-) From jhunter at servlets.com Tue Aug 30 15:15:17 2011 From: jhunter at servlets.com (Jason Hunter) Date: Tue, 30 Aug 2011 15:15:17 -0700 Subject: [jdom-interest] Preparing JDOM 1.1.2 ? In-Reply-To: <2b5387045b45787a1ae51a31006c370f@tuis.net> References: <2b5387045b45787a1ae51a31006c370f@tuis.net> Message-ID: <903C57B2-8752-43B5-914C-7EBEF19B17F5@servlets.com> On Aug 25, 2011, at 11:50 AM, Rolf Lear wrote: > Hi all > > Jason, the way I understand it is that we are intending a 1.1.2 release. > There are some issues in GitHub targeting that release. > > I think it is worth discussing some fixes for a JDOM 1.1.2 release. > > Currently the list of 1.1.2 Milestone issues is: > #1 Namespace for default attributes from XMLSchema > https://github.com/hunterhacker/jdom/issues/1 > #3 Should have a build in Maven Central > https://github.com/hunterhacker/jdom/issues/3 > > > I am unsure of how much priority should be put on 1.1.2 items. On the one > hand, I think that these issues are high priority, and should be addressed. > On the other hand, I find it hard to figure out where to draw the line. My general feeling is we should do a 1.1.2 with any bug fixes that are low-risk, don't introduce any compatibility issues, and will be coded up soon. > Also, the Maven issue is probably quite disruptive in terms of code > impact.... and, I feel it would be a lot of effort to 'mavenize' both 1.1.2 > and 2.0... I see that issue (#3) as being a 2.0 milestone, not 1.1.2 Why the code impact? I wasn't suggesting we use Maven, just put builds out there so others who use Maven can fetch JDOM builds. Looks like others have been doing this for us up til now: http://mvnrepository.com/artifact/jdom/jdom > There are some other issues already filed which could be part of 1.1.2, > but no-one has properly addressed. Things like > https://github.com/hunterhacker/jdom/issues/9 - BaseURI not output. > > Also, what I am finding is that as I go through adding JUnit tests I have > encountered a number of small issues. Each of them is trivial to fix (so > far, anyway), but, when taken together, there are enough to warrant a 1.1.2 > release. Further, I am sure that there will be even more as I cover more of > the JDOM code. I have been itemizing these small issues in GitHub as I go > so that I can 'document' what has changed, but the same items can be used > to fix 1.1.2. > > I have been concentrating on the JDOM2 coverage, but, I think it would > make sense to also get a 1.1.2 branch going, and clearing up some of the > 1.1.2 issues. > > That is, assuming we are planning a 1.1.2 release.... we are, aren't we? It seems like a good idea, targeted to people who are conservative. > > I have inspected the branch on GitHub labeled as JDOM-1.1.1. There is one > difference between that branch, and the actual code released as 1.1.1, and > that is commit > https://github.com/hunterhacker/jdom/commit/ea30b1e2b614f4b7d49de8a95af71fe3fb52ae2b > > It seems to me that I can move the 1.1.1 branch back up one commit, and > then branch the 1.1.2 from where the 1.1.1 was. it seems simple in my head, > but I will have to research the best way to do it in my head. Cool. Please when you're done add to the wiki how you did it, since it'll help all us git-noobs learn. BTW, I have git-guru friends if we need to ask them. > Once we get a 1.1.2 branch going it should be easy for me to apply any > fixes to both 2.0 and 1.1.2 (if we agree that they should be back-ported to > 1.1.2). > > Anyway, the way I see it is that a 1.1.2 release should be 'planned' ( - > or completely dismissed and just roll things in to 2.0.0). I feel like there would be demand for a 1.1.2 that's basically a risk-free drop-in upgrade for people on 1.1.1 that includes some fixes. -jh- From jdom at tuis.net Wed Aug 31 22:22:01 2011 From: jdom at tuis.net (Rolf) Date: Thu, 01 Sep 2011 01:22:01 -0400 Subject: [jdom-interest] Preparing JDOM 1.1.2 ? In-Reply-To: <903C57B2-8752-43B5-914C-7EBEF19B17F5@servlets.com> References: <2b5387045b45787a1ae51a31006c370f@tuis.net> <903C57B2-8752-43B5-914C-7EBEF19B17F5@servlets.com> Message-ID: <4E5F1679.6010403@tuis.net> Hi all. I have set up the process/infrastructure for JDOM 1.1.2 I initially set up the github branches incorrectly. I used 'branch' structures to indicate previous JDOM releases, when I should have used plain tags. So, I have removed the branch called jdom-1.1.1 and instead created a tag called jdom-1.1.1 (I also moved it from the revision it was on to the actual revision used for jdom-1.1.1). I have now created a branch jdom-1.x which will be used as the development branch for future pre-JDOM2 development/fixes. The process for the above changes can be read up on at: https://github.com/hunterhacker/jdom/wiki/Source-Branches-and-JDOM2 (see the update near the bottom...). I have gone through the issues (open and closed) in github and I have 'labelled' those issues I believe are good for backporting to jdom-1.1.2 If any new issues arise, or if anyone thinks there are issues on that list which should or should not be backported to 1.1.2 then please speak up. I intend to start working on the backport quite soon (it should be really quick and easy). The bigger problem is that I have not yet finished the junit testing, so there may be some more issues that arise. I expec that by the end of next week the junit testing will be sufficient for JDOM2 work. Rolf On 30/08/2011 6:15 PM, Jason Hunter wrote: > On Aug 25, 2011, at 11:50 AM, Rolf Lear wrote: > >> Hi all >> >> Jason, the way I understand it is that we are intending a 1.1.2 release. >> There are some issues in GitHub targeting that release. >> >> I think it is worth discussing some fixes for a JDOM 1.1.2 release. >> >> Currently the list of 1.1.2 Milestone issues is: >> #1 Namespace for default attributes from XMLSchema >> https://github.com/hunterhacker/jdom/issues/1 >> #3 Should have a build in Maven Central >> https://github.com/hunterhacker/jdom/issues/3 >> >> >> I am unsure of how much priority should be put on 1.1.2 items. On the one >> hand, I think that these issues are high priority, and should be addressed. >> On the other hand, I find it hard to figure out where to draw the line. > > My general feeling is we should do a 1.1.2 with any bug fixes that are low-risk, don't introduce any compatibility issues, and will be coded up soon. > >> Also, the Maven issue is probably quite disruptive in terms of code >> impact.... and, I feel it would be a lot of effort to 'mavenize' both 1.1.2 >> and 2.0... I see that issue (#3) as being a 2.0 milestone, not 1.1.2 > > Why the code impact? I wasn't suggesting we use Maven, just put builds out there so others who use Maven can fetch JDOM builds. Looks like others have been doing this for us up til now: > > http://mvnrepository.com/artifact/jdom/jdom > >> There are some other issues already filed which could be part of 1.1.2, >> but no-one has properly addressed. Things like >> https://github.com/hunterhacker/jdom/issues/9 - BaseURI not output. >> >> Also, what I am finding is that as I go through adding JUnit tests I have >> encountered a number of small issues. Each of them is trivial to fix (so >> far, anyway), but, when taken together, there are enough to warrant a 1.1.2 >> release. Further, I am sure that there will be even more as I cover more of >> the JDOM code. I have been itemizing these small issues in GitHub as I go >> so that I can 'document' what has changed, but the same items can be used >> to fix 1.1.2. >> >> I have been concentrating on the JDOM2 coverage, but, I think it would >> make sense to also get a 1.1.2 branch going, and clearing up some of the >> 1.1.2 issues. >> >> That is, assuming we are planning a 1.1.2 release.... we are, aren't we? > > It seems like a good idea, targeted to people who are conservative. > >> >> I have inspected the branch on GitHub labeled as JDOM-1.1.1. There is one >> difference between that branch, and the actual code released as 1.1.1, and >> that is commit >> https://github.com/hunterhacker/jdom/commit/ea30b1e2b614f4b7d49de8a95af71fe3fb52ae2b >> >> It seems to me that I can move the 1.1.1 branch back up one commit, and >> then branch the 1.1.2 from where the 1.1.1 was. it seems simple in my head, >> but I will have to research the best way to do it in my head. > > Cool. Please when you're done add to the wiki how you did it, since it'll help all us git-noobs learn. BTW, I have git-guru friends if we need to ask them. > >> Once we get a 1.1.2 branch going it should be easy for me to apply any >> fixes to both 2.0 and 1.1.2 (if we agree that they should be back-ported to >> 1.1.2). >> >> Anyway, the way I see it is that a 1.1.2 release should be 'planned' ( - >> or completely dismissed and just roll things in to 2.0.0). > > I feel like there would be demand for a 1.1.2 that's basically a risk-free drop-in upgrade for people on 1.1.1 that includes some fixes. > > -jh- > From jdom at tuis.net Wed Aug 31 22:36:42 2011 From: jdom at tuis.net (Rolf) Date: Thu, 01 Sep 2011 01:36:42 -0400 Subject: [jdom-interest] Preparing JDOM 1.1.2 ? In-Reply-To: <4E5711DB.1030403@tuis.net> References: <2b5387045b45787a1ae51a31006c370f@tuis.net> <4E5711DB.1030403@tuis.net> Message-ID: <4E5F19EA.30702@tuis.net> I have committed the change I suggested in to the JDOM2 branch (master). https://github.com/hunterhacker/jdom/commit/7ff5828dffdda871f418632604df0739c76651a5 This has helped me by allowing me put through 'passing' junit tests on the JDOM2 code base. On the other hand, I have spent a number of hours (too many) considering this issue, and am still not 100% satisfied with the options, etc. Specifically, I investigated using an XMLFilter for the SAX Parser and while it seems like a good idea at first, it quickly becomes a problem when you realize that the filter would have to keep track of a complete namespace stack in order to choose/build the correct prefix on the occasions that it is needed. This is inconvenient for the same reason that Thomas's patch, that it has to duplicate the bulk of the complexity of namespace tracking that is already built in to JDOM. Additionally, I am not happy with the fact that the only parser I hav tested has been xerces. That feels like bad planning. So, I have pushed through my code fix as a stop-gap, until someone can think of a better solution.... or until the 'feeder' systems (xerces) themselves are fixed. If by the end of next week (about the 9th september) there is still no better alternative then I will likely push the same fix through in to the 1.1.2 release. Rolf On 25/08/2011 11:24 PM, Rolf Lear wrote: > On 25/08/2011 9:54 PM, Elliotte Rusty Harold wrote: >> I don't have a github account but something is off here, and it may >> not be JDOM. Jason says: >> >> "I did a simple test and printed out what was being given to SAXHandler >> by the parser. Sure enough, on this document when validation is turn >> on, the SAX parser is reporting two attributes with the same qname >> (which happens to be the local name since they are both unprefix), but >> in different namespaces." >> >> That should *NOT* be happening. There is no such thing as an >> unprefixed attribute that is in a namespace. That simply does not >> exist in XML. If the parser is reporting such an attribute, the parser >> is *wrong*. If XML Schema can define an unprefixed attribute in a >> namespace, then XML Schema is *wrong*. >> > > Hi Elliotte > > I think everyone is in violent agreement here... it sucks, and it's > 'wrong'. > > XMLSchema should make it clear what should happen in this case, but XSD > 1.0 is 'clear' that it should do nothing, and XSD 1.1 has partial > coverage of the issue... (or, if you interpret it in just the right way, > it does cover it, and say the prefix should be generated by the parser). > > Xerces (the parser) currently takes the XSD1.0 view, and claims that > it's 'right' to not be prefixing the attributes. > > JDOM is the victim (other than the end user like Thomas) because it is > getting bad information, and then doing worse things with it. > > Michael filed a 'ticket' against XMLSchema (1.1) to clarify/resolve it. > You can see the discussion at: > http://www.w3.org/Bugs/Public/show_bug.cgi?id=13750 > > I filed a ticket against xerces at: > https://issues.apache.org/jira/browse/XERCESJ-1524 > > Then there is the JDOM issue at: > https://github.com/hunterhacker/jdom/issues/1 > > ahh, you found it. > > Rolf > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From jdom at tuis.net Wed Aug 31 22:46:34 2011 From: jdom at tuis.net (Rolf) Date: Thu, 01 Sep 2011 01:46:34 -0400 Subject: [jdom-interest] JDOM-1.1.2 and Maven Message-ID: <4E5F1C3A.9050302@tuis.net> Hi all The intention is to make a Maven resource available officially with the 1.1.2 JDOM release. This has been requested often enough.. ;-) The idea is to just make the jdom-1.1.2 jar available on the maven repository, not to do a full-scale 'mavenization' of the code, etc. Remember, we are talking 1.1.2 here. Is anyone willing to figure out what it would take to make this happen? The solution to the 1.1.2 process would possibly be a precursor to a more comprehensive JDOM2 process. I am hoping that this can be done in such a way that I don't have to take the time and familiarize myself with the maven process right now, but I can defer my own education for a few weeks or so. Hopefully someone can 'just do it' and either push it directly, or give me a recipe I can just follow and not have to think about too much. Anyone? Rolf From jdom at tuis.net Wed Aug 31 22:54:52 2011 From: jdom at tuis.net (Rolf) Date: Thu, 01 Sep 2011 01:54:52 -0400 Subject: [jdom-interest] Entity Resolver Cache/Catalog In-Reply-To: References: Message-ID: <4E5F1E2C.3090706@tuis.net> Hi Paul. Interesting read. Thanks. I have been reading up on your alternatives, and I have been trying to think of how they can be applied to JDOM. The problem I see is that properties are xerces specific. For the moment I have done a few things... 1. converted the XML test-cases to use local files for resources, not the web. 2. I have investigated your code, and code options. I have read up on OASIS, xcatalog, etc. 3. I have continued playing with a 'CachingEntityResolver' that I was playing with on the weekend. I was thinking that if I come up with a reliable cachingEntityResolver it could be put in the contrib section, and just added to a SAX/DOM Builder. Can you think of a good way to make the process more generic, but still easy? Rolf On 29/08/2011 11:15 AM, Paul Libbrecht wrote: > > Le 29 ao?t 2011 ? 16:58, Rolf Lear a ?crit : > >> This is further compounded by there being some restrictions on some >> documents too, like the w3.org 'ban' on default Java user-agents: >> http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic/ >> >> My experimentation indicates that w3.org has put a blanket 'tarpit' of 30 >> seconds on any connection, regardless of what User-agent you use. This is >> 'significant'. > > Definitely, W3C wants you to stop reference DTDs by their URL-URIs. > Well... it wants the parsers to stop keep parsing them. > >> Typical solutions to this problem are things like OASIS catalogs, etc. but >> that feels heavy-weight... or, is it? > > I believe it was not very hard to configure the java-shipped Xerces with catalogs. > And I would encourage the JDOM code to encourage this by showing good practice. > > Here's what I used before SAXparsing: > >> SAXParserFactory factory = SAXParserFactory.newInstance(); >> System.setProperty("com.sun.org.apache.xerces.xni.parser.XMLParserConfiguration", >> "com.sun.org.apache.xerces.parsers.XMLGrammarCachingConfiguration"); >> SAXParser parser = factory.newSAXParser(); >> >> XMLCatalogResolver resolver = new XMLCatalogResolver(); >> resolver.setPreferPublic(true); >> resolver.setCatalogList(new String[]{this.getClass().getResource("xmlCatalog.xml").toExternalForm()}); >> handler = new EventDeserializerSAXHandler(resolver); >> if(LOG.isDebugEnabled()) LOG.debug("Starting parser."); >> parser.parse(inputStream, handler); > > Caching, however, is for free with a single system-property (within the vm lifecycle) if I remember well. > > It would be cool to have SAXBuilder.setCatalog to make JDOM a good citizen! > (or even better: SAXBuilder.addCatalogEntry(public, URL) with a javadoc example where the URL is using class.getResource(). > > paul > also often developing in train ;-) >