From thomas.scheffler at uni-jena.de Wed Jul 20 06:23:49 2011
From: thomas.scheffler at uni-jena.de (Thomas Scheffler)
Date: Wed, 20 Jul 2011 15:23:49 +0200
Subject: [jdom-interest] Parsing a MODS-document with validation fails
Message-ID: <4E26D6E5.2010309@uni-jena.de>
Hi,
if I parse a valid MODS document with XML Schema validation, JDOM
changes attributes as it handles default values of schema not correctly
(by ignoring the namespace).
Here is a short code to demonstrate this:
SAXBuilder builder = new SAXBuilder(true);
builder.setFeature("http://xml.org/sax/features/namespaces", true);
builder.setFeature("http://xml.org/sax/features/namespace-prefixes", true);
builder.setFeature("http://apache.org/xml/features/validation/schema",
true);
Document document = builder.build(new
URL("http://academiccommons.columbia.edu/download/fedora_content/show_pretty/ac:111060/CONTENT/ac111060_description.xml"));
XMLOutputter xout = new XMLOutputter(Format.getPrettyFormat());
xout.output(document, System.out);
Here is a result fragment:
<name type="simple">
<namePart type="family">Edwards</namePart>
<namePart type="given">Stephen A.</namePart>
<role>
<roleTerm type="text">author</roleTerm>
</role>
<affiliation>Columbia University. Computer Science</affiliation>
</name>
If you look at the original document you can see, that @type of name is
"personal". The "simple" comes from the xlink XML-Schema that was
included by the MODS-Schema. Therefor the result fragment should look
like this:
<name type="personal" xlink:type="simple">
<namePart type="family">Edwards</namePart>
<namePart type="given">Stephen A.</namePart>
<role>
<roleTerm type="text">author</roleTerm>
</role>
<affiliation>Columbia University. Computer Science</affiliation>
</name>
If I use DOM from Java this is done correctly (but a bit ugly as it does
not use the namespace prefix already defined).
Could someone just fix this, please?
Regards,
Thomas Scheffler
From bshuffman at gmail.com Wed Jul 20 19:18:58 2011
From: bshuffman at gmail.com (Bradley S. Huffman)
Date: Wed, 20 Jul 2011 21:18:58 -0500
Subject: [jdom-interest] Parsing a MODS-document with validation fails
In-Reply-To: <4E26D6E5.2010309@uni-jena.de>
References: <4E26D6E5.2010309@uni-jena.de>
Message-ID: <CANq13Gu-rCw0oDgcHMcyOLqSCpoDiV-Y+tt-Ev1CMiTRpzCqRQ@mail.gmail.com>
Which version of JDOM? My first guess is it is something in XMLOutputter.
On Wed, Jul 20, 2011 at 8:23 AM, Thomas Scheffler
<thomas.scheffler at uni-jena.de> wrote:
> Hi,
>
> if I parse a valid MODS document with XML Schema validation, JDOM changes
> attributes as it handles default values of schema not correctly (by ignoring
> the namespace).
>
> Here is a short code to demonstrate this:
>
> SAXBuilder builder = new SAXBuilder(true);
> builder.setFeature("http://xml.org/sax/features/namespaces", true);
> builder.setFeature("http://xml.org/sax/features/namespace-prefixes", true);
> builder.setFeature("http://apache.org/xml/features/validation/schema",
> true);
>
> Document document = builder.build(new
> URL("http://academiccommons.columbia.edu/download/fedora_content/show_pretty/ac:111060/CONTENT/ac111060_description.xml"));
> XMLOutputter xout = new XMLOutputter(Format.getPrettyFormat());
> xout.output(document, System.out);
>
> Here is a result fragment:
>
> <name type="simple">
> <namePart type="family">Edwards</namePart>
> <namePart type="given">Stephen A.</namePart>
> <role>
> <roleTerm type="text">author</roleTerm>
> </role>
> <affiliation>Columbia University. Computer Science</affiliation>
> </name>
>
> If you look at the original document you can see, that @type of name is
> "personal". The "simple" comes from the xlink XML-Schema that was included
> by the MODS-Schema. Therefor the result fragment should look like this:
>
> <name type="personal" xlink:type="simple">
> <namePart type="family">Edwards</namePart>
> <namePart type="given">Stephen A.</namePart>
> <role>
> <roleTerm type="text">author</roleTerm>
> </role>
> <affiliation>Columbia University. Computer Science</affiliation>
> </name>
>
> If I use DOM from Java this is done correctly (but a bit ugly as it does not
> use the namespace prefix already defined).
>
> Could someone just fix this, please?
>
> Regards,
>
> Thomas Scheffler
> _______________________________________________
> 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 Thu Jul 21 01:14:36 2011
From: thomas.scheffler at uni-jena.de (Thomas Scheffler)
Date: Thu, 21 Jul 2011 10:14:36 +0200
Subject: [jdom-interest] Parsing a MODS-document with validation fails
In-Reply-To: <CANq13Gu-rCw0oDgcHMcyOLqSCpoDiV-Y+tt-Ev1CMiTRpzCqRQ@mail.gmail.com>
References: <4E26D6E5.2010309@uni-jena.de>
<CANq13Gu-rCw0oDgcHMcyOLqSCpoDiV-Y+tt-Ev1CMiTRpzCqRQ@mail.gmail.com>
Message-ID: <4E27DFEC.80902@uni-jena.de>
Am 21.07.2011 04:18, schrieb Bradley S. Huffman:
> Which version of JDOM? My first guess is it is something in XMLOutputter.
This is the latest and greatest 1.1.1. I would not suspect XMLOutputter
here as it usually does not have any problems with namespaces. This
seems to be a parsing issue.
regards
Thomas Scheffler
>
> On Wed, Jul 20, 2011 at 8:23 AM, Thomas Scheffler
> <thomas.scheffler at uni-jena.de> wrote:
>> Hi,
>>
>> if I parse a valid MODS document with XML Schema validation, JDOM changes
>> attributes as it handles default values of schema not correctly (by ignoring
>> the namespace).
>>
>> Here is a short code to demonstrate this:
>>
>> SAXBuilder builder = new SAXBuilder(true);
>> builder.setFeature("http://xml.org/sax/features/namespaces", true);
>> builder.setFeature("http://xml.org/sax/features/namespace-prefixes", true);
>> builder.setFeature("http://apache.org/xml/features/validation/schema",
>> true);
>>
>> Document document = builder.build(new
>> URL("http://academiccommons.columbia.edu/download/fedora_content/show_pretty/ac:111060/CONTENT/ac111060_description.xml"));
>> XMLOutputter xout = new XMLOutputter(Format.getPrettyFormat());
>> xout.output(document, System.out);
>>
>> Here is a result fragment:
>>
>> <name type="simple">
>> <namePart type="family">Edwards</namePart>
>> <namePart type="given">Stephen A.</namePart>
>> <role>
>> <roleTerm type="text">author</roleTerm>
>> </role>
>> <affiliation>Columbia University. Computer Science</affiliation>
>> </name>
>>
>> If you look at the original document you can see, that @type of name is
>> "personal". The "simple" comes from the xlink XML-Schema that was included
>> by the MODS-Schema. Therefor the result fragment should look like this:
>>
>> <name type="personal" xlink:type="simple">
>> <namePart type="family">Edwards</namePart>
>> <namePart type="given">Stephen A.</namePart>
>> <role>
>> <roleTerm type="text">author</roleTerm>
>> </role>
>> <affiliation>Columbia University. Computer Science</affiliation>
>> </name>
>>
>> If I use DOM from Java this is done correctly (but a bit ugly as it does not
>> use the namespace prefix already defined).
>>
>> Could someone just fix this, please?
--
Thomas Scheffler
Friedrich-Schiller-Universit?t Jena
Th?ringer Universit?ts- und Landesbibliothek
Bibliotheksplatz 2
07743 Jena
Phone: ++49 3641 940027
FAX: ++49 3641 940022
From thomas.scheffler at uni-jena.de Thu Jul 21 07:08:46 2011
From: thomas.scheffler at uni-jena.de (Thomas Scheffler)
Date: Thu, 21 Jul 2011 16:08:46 +0200
Subject: [jdom-interest] jdom 2.0 with generics
In-Reply-To: <4E282315.1050701@peralex.com>
References: <4E282315.1050701@peralex.com>
Message-ID: <4E2832EE.7010209@uni-jena.de>
Am 21.07.2011 15:01, schrieb Noel Grandin:
> Hi
>
> Would there be any interest in doing a JDOM 2.0 targeting java 1.5+, but
> changing return types to use generics?
>
> I'd be happy to produce some patches, they're pretty straightforward.
>
> And I know I'd appreciate cleaning up some of code with better type
> checking.
Hi,
this topic has been around some time now. And the main concern was that
this change would break backward compatibility. Beside that using
generics would be great, as JAVA 5 itself is unsupported since 2009 now.
So if current code runs without changes: +1 from me.
regards,
Thomas
From J.Dalton at ed.ac.uk Thu Jul 21 08:05:15 2011
From: J.Dalton at ed.ac.uk (J Dalton)
Date: Thu, 21 Jul 2011 16:05:15 +0100
Subject: [jdom-interest] jdom 2.0 with generics
In-Reply-To: <4E2832EE.7010209@uni-jena.de>
References: <4E282315.1050701@peralex.com>
<4E2832EE.7010209@uni-jena.de>
Message-ID: <CAO9ToVgpcRiWJM1Fwhmf6N=Hcc63wjFyiNaOQgZ2kJaei-poPA@mail.gmail.com>
If it breaks backward compatibility, surely those who do not
want to (or are unable to) change their code could continue
to use the earlier versions.
That JDOM doesn't use generics has unfortunately become
an argument against using JDOM.
-- Jeff
2011/7/21 Thomas Scheffler <thomas.scheffler at uni-jena.de>:
> Am 21.07.2011 15:01, schrieb Noel Grandin:
>>
>> Hi
>>
>> Would there be any interest in doing a JDOM 2.0 targeting java 1.5+, but
>> changing return types to use generics?
>>
>> I'd be happy to produce some patches, they're pretty straightforward.
>>
>> And I know I'd appreciate cleaning up some of code with better type
>> checking.
>
> Hi,
>
> this topic has been around some time now. And the main concern was that this
> change would break backward compatibility. Beside that using generics would
> be great, as JAVA 5 itself is unsupported since 2009 now.
>
> So if current code runs without changes: +1 from me.
>
> regards,
>
> Thomas
> _______________________________________________
> To control your jdom-interest membership:
> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com
>
From olivier.jaquemet at jalios.com Thu Jul 21 08:23:51 2011
From: olivier.jaquemet at jalios.com (Olivier Jaquemet)
Date: Thu, 21 Jul 2011 17:23:51 +0200
Subject: [jdom-interest] jdom 2.0 with generics
In-Reply-To: <CAO9ToVgpcRiWJM1Fwhmf6N=Hcc63wjFyiNaOQgZ2kJaei-poPA@mail.gmail.com>
References: <4E282315.1050701@peralex.com> <4E2832EE.7010209@uni-jena.de>
<CAO9ToVgpcRiWJM1Fwhmf6N=Hcc63wjFyiNaOQgZ2kJaei-poPA@mail.gmail.com>
Message-ID: <4E284487.7060602@jalios.com>
To that regard, I like the approach taken by several libraries when
making important change with backward compatibility, specially for
Generics.
They change the package name ! That way, the only thing required for the
developper wanting to use the new version is a simple modification of
the import directive + the generics modification is required. And code
using the older library can be left untouched.
For example, apache commons lang 3.0 which has been release two days ago
is using this approach.
import org.apache.commons.lang -> import org.apache.commons.lang3
It allows older version of the library to seat next to the new one
without any glitches.
So +1 for JDom 2 with generics with a package name change.
On 21/07/2011 17:05, J Dalton wrote:
> If it breaks backward compatibility, surely those who do not
> want to (or are unable to) change their code could continue
> to use the earlier versions.
>
> That JDOM doesn't use generics has unfortunately become
> an argument against using JDOM.
>
> -- Jeff
>
> 2011/7/21 Thomas Scheffler<thomas.scheffler at uni-jena.de>:
>> Am 21.07.2011 15:01, schrieb Noel Grandin:
>>> Hi
>>>
>>> Would there be any interest in doing a JDOM 2.0 targeting java 1.5+, but
>>> changing return types to use generics?
>>>
>>> I'd be happy to produce some patches, they're pretty straightforward.
>>>
>>> And I know I'd appreciate cleaning up some of code with better type
>>> checking.
>> Hi,
>>
>> this topic has been around some time now. And the main concern was that this
>> change would break backward compatibility. Beside that using generics would
>> be great, as JAVA 5 itself is unsupported since 2009 now.
>>
>> So if current code runs without changes: +1 from me.
>>
>> regards,
>>
>> Thomas
>> _______________________________________________
>> 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
>
--
Olivier Jaquemet<olivier.jaquemet at jalios.com>
Ing?nieur R&D Jalios S.A. - http://www.jalios.com/
@OlivierJaquemet +33970461480
From mikeb at mitre.org Thu Jul 21 08:37:24 2011
From: mikeb at mitre.org (Brenner, Mike)
Date: Thu, 21 Jul 2011 11:37:24 -0400
Subject: [jdom-interest] jdom 2.0 with generics
In-Reply-To: <4E284487.7060602@jalios.com>
References: <4E282315.1050701@peralex.com> <4E2832EE.7010209@uni-jena.de>
<CAO9ToVgpcRiWJM1Fwhmf6N=Hcc63wjFyiNaOQgZ2kJaei-poPA@mail.gmail.com>
<4E284487.7060602@jalios.com>
Message-ID: <2A8C361000E22F4895ACA58412E8F06C03D2CD2EFE@IMCMBX3.MITRE.ORG>
I agree -- go forward with backwards compatibility.
-----Original Message-----
From: jdom-interest-bounces at jdom.org [mailto:jdom-interest-bounces at jdom.org] On Behalf Of Olivier Jaquemet
Sent: Thursday, July 21, 2011 11:24 AM
To: J Dalton
Cc: Thomas Scheffler; jdom-interest at jdom.org
Subject: Re: [jdom-interest] jdom 2.0 with generics
To that regard, I like the approach taken by several libraries when
making important change with backward compatibility, specially for
Generics.
They change the package name ! That way, the only thing required for the
developper wanting to use the new version is a simple modification of
the import directive + the generics modification is required. And code
using the older library can be left untouched.
For example, apache commons lang 3.0 which has been release two days ago
is using this approach.
import org.apache.commons.lang -> import org.apache.commons.lang3
It allows older version of the library to seat next to the new one
without any glitches.
So +1 for JDom 2 with generics with a package name change.
On 21/07/2011 17:05, J Dalton wrote:
> If it breaks backward compatibility, surely those who do not
> want to (or are unable to) change their code could continue
> to use the earlier versions.
>
> That JDOM doesn't use generics has unfortunately become
> an argument against using JDOM.
>
> -- Jeff
>
> 2011/7/21 Thomas Scheffler<thomas.scheffler at uni-jena.de>:
>> Am 21.07.2011 15:01, schrieb Noel Grandin:
>>> Hi
>>>
>>> Would there be any interest in doing a JDOM 2.0 targeting java 1.5+, but
>>> changing return types to use generics?
>>>
>>> I'd be happy to produce some patches, they're pretty straightforward.
>>>
>>> And I know I'd appreciate cleaning up some of code with better type
>>> checking.
>> Hi,
>>
>> this topic has been around some time now. And the main concern was that this
>> change would break backward compatibility. Beside that using generics would
>> be great, as JAVA 5 itself is unsupported since 2009 now.
>>
>> So if current code runs without changes: +1 from me.
>>
>> regards,
>>
>> Thomas
>> _______________________________________________
>> 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
>
--
Olivier Jaquemet<olivier.jaquemet at jalios.com>
Ing?nieur R&D Jalios S.A. - http://www.jalios.com/
@OlivierJaquemet +33970461480
_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com
From bob_jacobsen at lbl.gov Thu Jul 21 09:23:25 2011
From: bob_jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 21 Jul 2011 09:23:25 -0700
Subject: [jdom-interest] jdom 2.0 with generics
In-Reply-To: <7371847E-4174-4356-82DA-205087597E92@activemath.org>
References: <4E282315.1050701@peralex.com> <4E2832EE.7010209@uni-jena.de>
<CAO9ToVgpcRiWJM1Fwhmf6N=Hcc63wjFyiNaOQgZ2kJaei-poPA@mail.gmail.com>
<4E284487.7060602@jalios.com>
<7371847E-4174-4356-82DA-205087597E92@activemath.org>
Message-ID: <0A600ECE-940D-43EC-9A9D-28E1E9D31230@lbl.gov>
On Jul 21, 2011, at 8:50 AM, Paul Libbrecht wrote:
>
> Le 21 juil. 2011 ? 17:23, Olivier Jaquemet a ?crit :
>
>> So +1 for JDom 2 with generics with a package name change.
>
> For me too.
> My +1.
>
And another!
Bob
From mike at saxonica.com Thu Jul 21 16:30:13 2011
From: mike at saxonica.com (Michael Kay)
Date: Fri, 22 Jul 2011 00:30:13 +0100
Subject: [jdom-interest] jdom 2.0 with generics
In-Reply-To: <4E28B3F6.9080501@tuis.net>
References: <4E282315.1050701@peralex.com> <4E2832EE.7010209@uni-jena.de><CAO9ToVgpcRiWJM1Fwhmf6N=Hcc63wjFyiNaOQgZ2kJaei-poPA@mail.gmail.com><4E284487.7060602@jalios.com> <7371847E-4174-4356-82DA-205087597E92@activemath.org> <FDCF327FDEE60B4C8F6FE237965A683D12B2AEFB@naeaphilez03v.nadsusea.nads.navy.mil>
<4E28B3F6.9080501@tuis.net>
Message-ID: <4E28B685.10808@saxonica.com>
> Additionally, the XPath support is pretty much impossible to accomplish.
>
For an attempt at a strongly-typed API for XPath processing, see Saxon's
s9api interface. It is of course oriented to the requirements of XPath
2.0. (But surely no-one wants to define a new API that only supports
XPath 1.0...)
Michael Kay
Saxonica
From jhunter at servlets.com Fri Jul 22 13:12:59 2011
From: jhunter at servlets.com (Jason Hunter)
Date: Fri, 22 Jul 2011 13:12:59 -0700
Subject: [jdom-interest] Parsing a MODS-document with validation fails
In-Reply-To: <4E2922F6.2020506@uni-jena.de>
References: <4E26D6E5.2010309@uni-jena.de> <CANq13Gu-rCw0oDgcHMcyOLqSCpoDiV-Y+tt-Ev1CMiTRpzCqRQ@mail.gmail.com>
<4E27DFEC.80902@uni-jena.de> <4E2922F6.2020506@uni-jena.de>
Message-ID: <BFAF6CE6-7B94-453B-AC23-293577616844@servlets.com>
Thanks, Thomas. I'll integrate it.
Anyone else sitting on a bug that could get fixed in 1.1.2?
-jh-
On Jul 22, 2011, at 12:12 AM, Thomas Scheffler wrote:
> Am 21.07.2011 10:14, schrieb Thomas Scheffler:
>> Am 21.07.2011 04:18, schrieb Bradley S. Huffman:
>>> Which version of JDOM? My first guess is it is something in XMLOutputter.
>>
>> This is the latest and greatest 1.1.1. I would not suspect XMLOutputter here as it usually does not have any problems with namespaces. This seems to be a parsing issue.
>
> It is a bug in the SAXHandler class where attributes with a different Namespace are only detected by their QName and not by the different Namespace-URI. I attached a patch that fixes this bug.
> It would be great, if this could be integrated and released soon in a version 1.1.2.
>
> regards
>
> Thomas Scheffler
>
>>>
>>> On Wed, Jul 20, 2011 at 8:23 AM, Thomas Scheffler
>>> <thomas.scheffler at uni-jena.de> wrote:
>>>> Hi,
>>>>
>>>> if I parse a valid MODS document with XML Schema validation, JDOM changes
>>>> attributes as it handles default values of schema not correctly (by ignoring
>>>> the namespace).
>>>>
>>>> Here is a short code to demonstrate this:
>>>>
>>>> SAXBuilder builder = new SAXBuilder(true);
>>>> builder.setFeature("http://xml.org/sax/features/namespaces", true);
>>>> builder.setFeature("http://xml.org/sax/features/namespace-prefixes", true);
>>>> builder.setFeature("http://apache.org/xml/features/validation/schema",
>>>> true);
>>>>
>>>> Document document = builder.build(new
>>>> URL("http://academiccommons.columbia.edu/download/fedora_content/show_pretty/ac:111060/CONTENT/ac111060_description.xml"));
>>>> XMLOutputter xout = new XMLOutputter(Format.getPrettyFormat());
>>>> xout.output(document, System.out);
>>>>
>>>> Here is a result fragment:
>>>>
>>>> <name type="simple">
>>>> <namePart type="family">Edwards</namePart>
>>>> <namePart type="given">Stephen A.</namePart>
>>>> <role>
>>>> <roleTerm type="text">author</roleTerm>
>>>> </role>
>>>> <affiliation>Columbia University. Computer Science</affiliation>
>>>> </name>
>>>>
>>>> If you look at the original document you can see, that @type of name is
>>>> "personal". The "simple" comes from the xlink XML-Schema that was included
>>>> by the MODS-Schema. Therefor the result fragment should look like this:
>>>>
>>>> <name type="personal" xlink:type="simple">
>>>> <namePart type="family">Edwards</namePart>
>>>> <namePart type="given">Stephen A.</namePart>
>>>> <role>
>>>> <roleTerm type="text">author</roleTerm>
>>>> </role>
>>>> <affiliation>Columbia University. Computer Science</affiliation>
>>>> </name>
>>>>
>>>> If I use DOM from Java this is done correctly (but a bit ugly as it does not
>>>> use the namespace prefix already defined).
>>>>
>>>> Could someone just fix this, please?
>>
>>
>
> <jdom-namespace.patch>_______________________________________________
> 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 Fri Jul 22 13:21:33 2011
From: thomas.scheffler at uni-jena.de (Thomas Scheffler)
Date: Fri, 22 Jul 2011 22:21:33 +0200
Subject: [jdom-interest] Parsing a MODS-document with validation fails
In-Reply-To: <BFAF6CE6-7B94-453B-AC23-293577616844@servlets.com>
References: <4E26D6E5.2010309@uni-jena.de> <CANq13Gu-rCw0oDgcHMcyOLqSCpoDiV-Y+tt-Ev1CMiTRpzCqRQ@mail.gmail.com>
<4E27DFEC.80902@uni-jena.de> <4E2922F6.2020506@uni-jena.de>
<BFAF6CE6-7B94-453B-AC23-293577616844@servlets.com>
Message-ID: <4E29DBCD.1080001@uni-jena.de>
Am 22.07.2011 22:12, schrieb Jason Hunter:
> Thanks, Thomas. I'll integrate it.
Thank you for responding and integrating it.
regards,
Thomas
> Am 21.07.2011 10:14, schrieb Thomas Scheffler:
>>> Am 21.07.2011 04:18, schrieb Bradley S. Huffman:
>>>> Which version of JDOM? My first guess is it is something in XMLOutputter.
>>> This is the latest and greatest 1.1.1. I would not suspect XMLOutputter here as it usually does not have any problems with namespaces. This seems to be a parsing issue.
>> It is a bug in the SAXHandler class where attributes with a different Namespace are only detected by their QName and not by the different Namespace-URI. I attached a patch that fixes this bug.
>> It would be great, if this could be integrated and released soon in a version 1.1.2.
>>
>> regards
>>
>> Thomas Scheffler
>>
>>>> On Wed, Jul 20, 2011 at 8:23 AM, Thomas Scheffler
>>>> <thomas.scheffler at uni-jena.de> wrote:
>>>>> Hi,
>>>>>
>>>>> if I parse a valid MODS document with XML Schema validation, JDOM changes
>>>>> attributes as it handles default values of schema not correctly (by ignoring
>>>>> the namespace).
>>>>>
>>>>> Here is a short code to demonstrate this:
>>>>>
>>>>> SAXBuilder builder = new SAXBuilder(true);
>>>>> builder.setFeature("http://xml.org/sax/features/namespaces", true);
>>>>> builder.setFeature("http://xml.org/sax/features/namespace-prefixes", true);
>>>>> builder.setFeature("http://apache.org/xml/features/validation/schema",
>>>>> true);
>>>>>
>>>>> Document document = builder.build(new
>>>>> URL("http://academiccommons.columbia.edu/download/fedora_content/show_pretty/ac:111060/CONTENT/ac111060_description.xml"));
>>>>> XMLOutputter xout = new XMLOutputter(Format.getPrettyFormat());
>>>>> xout.output(document, System.out);
>>>>>
>>>>> Here is a result fragment:
>>>>>
>>>>> <name type="simple">
>>>>> <namePart type="family">Edwards</namePart>
>>>>> <namePart type="given">Stephen A.</namePart>
>>>>> <role>
>>>>> <roleTerm type="text">author</roleTerm>
>>>>> </role>
>>>>> <affiliation>Columbia University. Computer Science</affiliation>
>>>>> </name>
>>>>>
>>>>> If you look at the original document you can see, that @type of name is
>>>>> "personal". The "simple" comes from the xlink XML-Schema that was included
>>>>> by the MODS-Schema. Therefor the result fragment should look like this:
>>>>>
>>>>> <name type="personal" xlink:type="simple">
>>>>> <namePart type="family">Edwards</namePart>
>>>>> <namePart type="given">Stephen A.</namePart>
>>>>> <role>
>>>>> <roleTerm type="text">author</roleTerm>
>>>>> </role>
>>>>> <affiliation>Columbia University. Computer Science</affiliation>
>>>>> </name>
>>>>>
>>>>> If I use DOM from Java this is done correctly (but a bit ugly as it does not
>>>>> use the namespace prefix already defined).
>>>>>
>>>>> Could someone just fix this, please?
From jhunter at servlets.com Fri Jul 22 13:33:27 2011
From: jhunter at servlets.com (Jason Hunter)
Date: Fri, 22 Jul 2011 13:33:27 -0700
Subject: [jdom-interest] jdom 2.0 with generics
In-Reply-To: <4E28BC97.80402@tuis.net>
References: <4E282315.1050701@peralex.com> <4E2832EE.7010209@uni-jena.de><CAO9ToVgpcRiWJM1Fwhmf6N=Hcc63wjFyiNaOQgZ2kJaei-poPA@mail.gmail.com><4E284487.7060602@jalios.com> <7371847E-4174-4356-82DA-205087597E92@activemath.org> <FDCF327FDEE60B4C8F6FE237965A683D12B2AEFB@naeaphilez03v.nadsusea.nads.navy.mil>
<4E28B3F6.9080501@tuis.net> <4E28BC97.80402@tuis.net>
Message-ID: <27527DC0-3636-427E-BB26-EDF42662523B@servlets.com>
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 <T>. Returning a null value indicates the filter does not match.
>
> public interface Filter <T extends Content> 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<Element> kids = someelement.getChildren();
> possible.
>
>
> 2. Modified Parent to be generic.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> This allows for the method:
> Parent<T> 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
From bshuffman at gmail.com Fri Jul 22 13:53:45 2011
From: bshuffman at gmail.com (Bradley S. Huffman)
Date: Fri, 22 Jul 2011 15:53:45 -0500
Subject: [jdom-interest] Parsing a MODS-document with validation fails
In-Reply-To: <BFAF6CE6-7B94-453B-AC23-293577616844@servlets.com>
References: <4E26D6E5.2010309@uni-jena.de>
<CANq13Gu-rCw0oDgcHMcyOLqSCpoDiV-Y+tt-Ev1CMiTRpzCqRQ@mail.gmail.com>
<4E27DFEC.80902@uni-jena.de> <4E2922F6.2020506@uni-jena.de>
<BFAF6CE6-7B94-453B-AC23-293577616844@servlets.com>
Message-ID: <CANq13Gt=abbbimtOuro=O0T9=r6c1OWMO5mLS5-upgUS3tSgLQ@mail.gmail.com>
I'm not sure about a patch that makes up a namespace prefix. From the patch
nsPrefixCount++;
ns = Namespace.getNamespace("ns" + nsPrefixCount, attUri);
Seems like a kludge. My gut says it's something else.
On Fri, Jul 22, 2011 at 3:12 PM, Jason Hunter <jhunter at servlets.com> wrote:
> Thanks, Thomas. ?I'll integrate it.
>
> Anyone else sitting on a bug that could get fixed in 1.1.2?
>
> -jh-
>
> On Jul 22, 2011, at 12:12 AM, Thomas Scheffler wrote:
>
>> Am 21.07.2011 10:14, schrieb Thomas Scheffler:
>>> Am 21.07.2011 04:18, schrieb Bradley S. Huffman:
>>>> Which version of JDOM? ?My first guess is it is something in XMLOutputter.
>>>
>>> This is the latest and greatest 1.1.1. I would not suspect XMLOutputter here as it usually does not have any problems with namespaces. This seems to be a parsing issue.
>>
>> It is a bug in the SAXHandler class where attributes with a different Namespace are only detected by their QName and not by the different Namespace-URI. I attached a patch that fixes this bug.
>> It would be great, if this could be integrated and released soon in a version 1.1.2.
>>
>> regards
>>
>> Thomas Scheffler
>>
>>>>
>>>> On Wed, Jul 20, 2011 at 8:23 AM, Thomas Scheffler
>>>> <thomas.scheffler at uni-jena.de> ?wrote:
>>>>> Hi,
>>>>>
>>>>> if I parse a valid MODS document with XML Schema validation, JDOM changes
>>>>> attributes as it handles default values of schema not correctly (by ignoring
>>>>> the namespace).
>>>>>
>>>>> Here is a short code to demonstrate this:
>>>>>
>>>>> SAXBuilder builder = new SAXBuilder(true);
>>>>> builder.setFeature("http://xml.org/sax/features/namespaces", true);
>>>>> builder.setFeature("http://xml.org/sax/features/namespace-prefixes", true);
>>>>> builder.setFeature("http://apache.org/xml/features/validation/schema",
>>>>> true);
>>>>>
>>>>> Document document = builder.build(new
>>>>> URL("http://academiccommons.columbia.edu/download/fedora_content/show_pretty/ac:111060/CONTENT/ac111060_description.xml"));
>>>>> XMLOutputter xout = new XMLOutputter(Format.getPrettyFormat());
>>>>> xout.output(document, System.out);
>>>>>
>>>>> Here is a result fragment:
>>>>>
>>>>> <name type="simple">
>>>>> <namePart type="family">Edwards</namePart>
>>>>> <namePart type="given">Stephen A.</namePart>
>>>>> <role>
>>>>> <roleTerm type="text">author</roleTerm>
>>>>> </role>
>>>>> <affiliation>Columbia University. Computer Science</affiliation>
>>>>> </name>
>>>>>
>>>>> If you look at the original document you can see, that @type of name is
>>>>> "personal". The "simple" comes from the xlink XML-Schema that was included
>>>>> by the MODS-Schema. Therefor the result fragment should look like this:
>>>>>
>>>>> <name type="personal" xlink:type="simple">
>>>>> <namePart type="family">Edwards</namePart>
>>>>> <namePart type="given">Stephen A.</namePart>
>>>>> <role>
>>>>> <roleTerm type="text">author</roleTerm>
>>>>> </role>
>>>>> <affiliation>Columbia University. Computer Science</affiliation>
>>>>> </name>
>>>>>
>>>>> If I use DOM from Java this is done correctly (but a bit ugly as it does not
>>>>> use the namespace prefix already defined).
>>>>>
>>>>> Could someone just fix this, please?
>>>
>>>
>>
>> <jdom-namespace.patch>_______________________________________________
>> 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 thomas.scheffler at uni-jena.de Fri Jul 22 14:08:55 2011
From: thomas.scheffler at uni-jena.de (Thomas Scheffler)
Date: Fri, 22 Jul 2011 23:08:55 +0200
Subject: [jdom-interest] Parsing a MODS-document with validation fails
In-Reply-To: <CANq13Gt=abbbimtOuro=O0T9=r6c1OWMO5mLS5-upgUS3tSgLQ@mail.gmail.com>
References: <4E26D6E5.2010309@uni-jena.de>
<CANq13Gu-rCw0oDgcHMcyOLqSCpoDiV-Y+tt-Ev1CMiTRpzCqRQ@mail.gmail.com>
<4E27DFEC.80902@uni-jena.de> <4E2922F6.2020506@uni-jena.de>
<BFAF6CE6-7B94-453B-AC23-293577616844@servlets.com>
<CANq13Gt=abbbimtOuro=O0T9=r6c1OWMO5mLS5-upgUS3tSgLQ@mail.gmail.com>
Message-ID: <4E29E6E7.9080708@uni-jena.de>
Am 22.07.2011 22:53, schrieb Bradley S. Huffman:
> I'm not sure about a patch that makes up a namespace prefix. From the patch
>
> nsPrefixCount++;
> ns = Namespace.getNamespace("ns" + nsPrefixCount, attUri);
>
>
> Seems like a kludge. My gut says it's something else.
This is how it is done by the Oracle JAVA DocumentBuilder. JDOM won't
accept a namespace without a prefix so you have to build some as the
SAXParser delivers an attribute with QName=LocalName. Before that I take
a look in predeclared namespaces, so that any prefix that is bound to an
URI is used before building a new one. For the testing case I submitted
in my original mail, "xlink" is found correctly which makes it more
beautiful than the DocumentBuilder solution that creates "ns0" on every
element with xlink:type set fixed to "simple". Hope you can follow my
arguments.
regards,
Thomas
> On Fri, Jul 22, 2011 at 3:12 PM, Jason Hunter<jhunter at servlets.com> wrote:
>> Thanks, Thomas. I'll integrate it.
>>
>> Anyone else sitting on a bug that could get fixed in 1.1.2?
>>
>> -jh-
>>
>> On Jul 22, 2011, at 12:12 AM, Thomas Scheffler wrote:
>>
>>> Am 21.07.2011 10:14, schrieb Thomas Scheffler:
>>>> Am 21.07.2011 04:18, schrieb Bradley S. Huffman:
>>>>> Which version of JDOM? My first guess is it is something in XMLOutputter.
>>>> This is the latest and greatest 1.1.1. I would not suspect XMLOutputter here as it usually does not have any problems with namespaces. This seems to be a parsing issue.
>>> It is a bug in the SAXHandler class where attributes with a different Namespace are only detected by their QName and not by the different Namespace-URI. I attached a patch that fixes this bug.
>>> It would be great, if this could be integrated and released soon in a version 1.1.2.
>>>
>>> regards
>>>
>>> Thomas Scheffler
>>>
>>>>> On Wed, Jul 20, 2011 at 8:23 AM, Thomas Scheffler
>>>>> <thomas.scheffler at uni-jena.de> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> if I parse a valid MODS document with XML Schema validation, JDOM changes
>>>>>> attributes as it handles default values of schema not correctly (by ignoring
>>>>>> the namespace).
>>>>>>
>>>>>> Here is a short code to demonstrate this:
>>>>>>
>>>>>> SAXBuilder builder = new SAXBuilder(true);
>>>>>> builder.setFeature("http://xml.org/sax/features/namespaces", true);
>>>>>> builder.setFeature("http://xml.org/sax/features/namespace-prefixes", true);
>>>>>> builder.setFeature("http://apache.org/xml/features/validation/schema",
>>>>>> true);
>>>>>>
>>>>>> Document document = builder.build(new
>>>>>> URL("http://academiccommons.columbia.edu/download/fedora_content/show_pretty/ac:111060/CONTENT/ac111060_description.xml"));
>>>>>> XMLOutputter xout = new XMLOutputter(Format.getPrettyFormat());
>>>>>> xout.output(document, System.out);
>>>>>>
>>>>>> Here is a result fragment:
>>>>>>
>>>>>> <name type="simple">
>>>>>> <namePart type="family">Edwards</namePart>
>>>>>> <namePart type="given">Stephen A.</namePart>
>>>>>> <role>
>>>>>> <roleTerm type="text">author</roleTerm>
>>>>>> </role>
>>>>>> <affiliation>Columbia University. Computer Science</affiliation>
>>>>>> </name>
>>>>>>
>>>>>> If you look at the original document you can see, that @type of name is
>>>>>> "personal". The "simple" comes from the xlink XML-Schema that was included
>>>>>> by the MODS-Schema. Therefor the result fragment should look like this:
>>>>>>
>>>>>> <name type="personal" xlink:type="simple">
>>>>>> <namePart type="family">Edwards</namePart>
>>>>>> <namePart type="given">Stephen A.</namePart>
>>>>>> <role>
>>>>>> <roleTerm type="text">author</roleTerm>
>>>>>> </role>
>>>>>> <affiliation>Columbia University. Computer Science</affiliation>
>>>>>> </name>
>>>>>>
>>>>>> If I use DOM from Java this is done correctly (but a bit ugly as it does not
>>>>>> use the namespace prefix already defined).
>>>>>>
>>>>>> Could someone just fix this, please?
From bshuffman at gmail.com Sun Jul 24 14:46:42 2011
From: bshuffman at gmail.com (Bradley S. Huffman)
Date: Sun, 24 Jul 2011 16:46:42 -0500
Subject: [jdom-interest] Parsing a MODS-document with validation fails
In-Reply-To: <4E29E6E7.9080708@uni-jena.de>
References: <4E26D6E5.2010309@uni-jena.de>
<CANq13Gu-rCw0oDgcHMcyOLqSCpoDiV-Y+tt-Ev1CMiTRpzCqRQ@mail.gmail.com>
<4E27DFEC.80902@uni-jena.de> <4E2922F6.2020506@uni-jena.de>
<BFAF6CE6-7B94-453B-AC23-293577616844@servlets.com>
<CANq13Gt=abbbimtOuro=O0T9=r6c1OWMO5mLS5-upgUS3tSgLQ@mail.gmail.com>
<4E29E6E7.9080708@uni-jena.de>
Message-ID: <CANq13GuA7OO_TueCNe5i_vXT=kAX6BKryRXZvvNpkJeTRzbV-w@mail.gmail.com>
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?
On Fri, Jul 22, 2011 at 4:08 PM, Thomas Scheffler
<thomas.scheffler at uni-jena.de> wrote:
> Am 22.07.2011 22:53, schrieb Bradley S. Huffman:
>>
>> I'm not sure about a patch that makes up a namespace prefix. ?From the
>> patch
>>
>> ? ? ? ? ? nsPrefixCount++;
>> ? ? ? ? ? ns = Namespace.getNamespace("ns" + nsPrefixCount, attUri);
>>
>>
>> Seems like a kludge. ?My gut says it's something else.
>
> This is how it is done by the Oracle JAVA DocumentBuilder. JDOM won't accept
> a namespace without a prefix so you have to build some as the SAXParser
> delivers an attribute with QName=LocalName. Before that I take a look in
> predeclared namespaces, so that any prefix that is bound to an URI is used
> before building a new one. For the testing case I submitted in my original
> mail, "xlink" is found correctly which makes it more beautiful than the
> DocumentBuilder solution that creates "ns0" on every element with xlink:type
> set fixed to "simple". Hope you can follow my arguments.
>
> regards,
>
> Thomas
>
>> On Fri, Jul 22, 2011 at 3:12 PM, Jason Hunter<jhunter at servlets.com>
>> ?wrote:
>>>
>>> Thanks, Thomas. ?I'll integrate it.
>>>
>>> Anyone else sitting on a bug that could get fixed in 1.1.2?
>>>
>>> -jh-
>>>
>>> On Jul 22, 2011, at 12:12 AM, Thomas Scheffler wrote:
>>>
>>>> Am 21.07.2011 10:14, schrieb Thomas Scheffler:
>>>>>
>>>>> Am 21.07.2011 04:18, schrieb Bradley S. Huffman:
>>>>>>
>>>>>> Which version of JDOM? ?My first guess is it is something in
>>>>>> XMLOutputter.
>>>>>
>>>>> This is the latest and greatest 1.1.1. I would not suspect XMLOutputter
>>>>> here as it usually does not have any problems with namespaces. This seems to
>>>>> be a parsing issue.
>>>>
>>>> It is a bug in the SAXHandler class where attributes with a different
>>>> Namespace are only detected by their QName and not by the different
>>>> Namespace-URI. I attached a patch that fixes this bug.
>>>> It would be great, if this could be integrated and released soon in a
>>>> version 1.1.2.
>>>>
>>>> regards
>>>>
>>>> Thomas Scheffler
>>>>
>>>>>> On Wed, Jul 20, 2011 at 8:23 AM, Thomas Scheffler
>>>>>> <thomas.scheffler at uni-jena.de> ? ?wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> if I parse a valid MODS document with XML Schema validation, JDOM
>>>>>>> changes
>>>>>>> attributes as it handles default values of schema not correctly (by
>>>>>>> ignoring
>>>>>>> the namespace).
>>>>>>>
>>>>>>> Here is a short code to demonstrate this:
>>>>>>>
>>>>>>> SAXBuilder builder = new SAXBuilder(true);
>>>>>>> builder.setFeature("http://xml.org/sax/features/namespaces", true);
>>>>>>> builder.setFeature("http://xml.org/sax/features/namespace-prefixes",
>>>>>>> true);
>>>>>>>
>>>>>>> builder.setFeature("http://apache.org/xml/features/validation/schema",
>>>>>>> true);
>>>>>>>
>>>>>>> Document document = builder.build(new
>>>>>>>
>>>>>>> URL("http://academiccommons.columbia.edu/download/fedora_content/show_pretty/ac:111060/CONTENT/ac111060_description.xml"));
>>>>>>> XMLOutputter xout = new XMLOutputter(Format.getPrettyFormat());
>>>>>>> xout.output(document, System.out);
>>>>>>>
>>>>>>> Here is a result fragment:
>>>>>>>
>>>>>>> <name type="simple">
>>>>>>> <namePart type="family">Edwards</namePart>
>>>>>>> <namePart type="given">Stephen A.</namePart>
>>>>>>> <role>
>>>>>>> <roleTerm type="text">author</roleTerm>
>>>>>>> </role>
>>>>>>> <affiliation>Columbia University. Computer Science</affiliation>
>>>>>>> </name>
>>>>>>>
>>>>>>> If you look at the original document you can see, that @type of name
>>>>>>> is
>>>>>>> "personal". The "simple" comes from the xlink XML-Schema that was
>>>>>>> included
>>>>>>> by the MODS-Schema. Therefor the result fragment should look like
>>>>>>> this:
>>>>>>>
>>>>>>> <name type="personal" xlink:type="simple">
>>>>>>> <namePart type="family">Edwards</namePart>
>>>>>>> <namePart type="given">Stephen A.</namePart>
>>>>>>> <role>
>>>>>>> <roleTerm type="text">author</roleTerm>
>>>>>>> </role>
>>>>>>> <affiliation>Columbia University. Computer Science</affiliation>
>>>>>>> </name>
>>>>>>>
>>>>>>> If I use DOM from Java this is done correctly (but a bit ugly as it
>>>>>>> does not
>>>>>>> use the namespace prefix already defined).
>>>>>>>
>>>>>>> Could someone just fix this, please?
>
> _______________________________________________
> 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 Mon Jul 25 00:05:00 2011
From: thomas.scheffler at uni-jena.de (Thomas Scheffler)
Date: Mon, 25 Jul 2011 09:05:00 +0200
Subject: [jdom-interest] Parsing a MODS-document with validation fails
In-Reply-To: <CANq13GuA7OO_TueCNe5i_vXT=kAX6BKryRXZvvNpkJeTRzbV-w@mail.gmail.com>
References: <4E26D6E5.2010309@uni-jena.de>
<CANq13Gu-rCw0oDgcHMcyOLqSCpoDiV-Y+tt-Ev1CMiTRpzCqRQ@mail.gmail.com>
<4E27DFEC.80902@uni-jena.de> <4E2922F6.2020506@uni-jena.de>
<BFAF6CE6-7B94-453B-AC23-293577616844@servlets.com>
<CANq13Gt=abbbimtOuro=O0T9=r6c1OWMO5mLS5-upgUS3tSgLQ@mail.gmail.com>
<4E29E6E7.9080708@uni-jena.de>
<CANq13GuA7OO_TueCNe5i_vXT=kAX6BKryRXZvvNpkJeTRzbV-w@mail.gmail.com>
Message-ID: <4E2D159C.30802@uni-jena.de>
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?
regards,
Thomas
>
> On Fri, Jul 22, 2011 at 4:08 PM, Thomas Scheffler
> <thomas.scheffler at uni-jena.de> wrote:
>> Am 22.07.2011 22:53, schrieb Bradley S. Huffman:
>>>
>>> I'm not sure about a patch that makes up a namespace prefix. From the
>>> patch
>>>
>>> nsPrefixCount++;
>>> ns = Namespace.getNamespace("ns" + nsPrefixCount, attUri);
>>>
>>>
>>> Seems like a kludge. My gut says it's something else.
>>
>> This is how it is done by the Oracle JAVA DocumentBuilder. JDOM won't accept
>> a namespace without a prefix so you have to build some as the SAXParser
>> delivers an attribute with QName=LocalName. Before that I take a look in
>> predeclared namespaces, so that any prefix that is bound to an URI is used
>> before building a new one. For the testing case I submitted in my original
>> mail, "xlink" is found correctly which makes it more beautiful than the
>> DocumentBuilder solution that creates "ns0" on every element with xlink:type
>> set fixed to "simple". Hope you can follow my arguments.
>>
>> regards,
>>
>> Thomas