XOM API for Processing XML with Java

[Nils_Kilden-Pedersen AT Countrywide.Com]

xom-interest-bounces AT lists.ibiblio.org wrote on 01/21/2005 10:47:53 AM:
> There will be a hard dependency on some XPath engine. Possibly in the 
> future that engine will change. I plan to explore SAXON 6.5.3, 
> especially if I can figure out how to fix the bugs in its XSLT support 
> so I could dump Xalan. But XPath support is only going to get more 
> deeply tied into XOM as 1.1 moves forward (i.e. it is likely other 
> methods are going to start depending on the correct operation of 
> Node.query()), so I'm not inclined to pull Jaxen out unless I've got a 
> replacement.

Will you consider repackaging the dependencies, thereby making them 
internal classes? This will make sense if you're going to modify the Saxon 
engine anyway.
>From whoschek AT lbl.gov  Fri Jan 21 14:18:06 2005
Return-Path: <whoschek AT lbl.gov>
X-Original-To: xom-interest AT lists.ibiblio.org
Delivered-To: xom-interest AT lists.ibiblio.org
Received: from mta1.lbl.gov (mta1.lbl.gov [128.3.41.24])
        by lists.ibiblio.org (Postfix) with ESMTP id 0BCB24C005
        for <xom-interest AT lists.ibiblio.org>;
        Fri, 21 Jan 2005 14:18:05 -0500 (EST)
Received: from mta1.lbl.gov (localhost [127.0.0.1])
        by mta1.lbl.gov (8.12.10/8.12.10) with ESMTP id j0LJI3km027879
        for <xom-interest AT lists.ibiblio.org>;
        Fri, 21 Jan 2005 11:18:03 -0800 (PST)
Received: from [10.0.4.198] (brewedawakening.oak.surfandsip.net
        [68.164.245.153])
        by mta1.lbl.gov (8.12.10/8.12.10) with ESMTP id j0LJI28i027855;
        Fri, 21 Jan 2005 11:18:02 -0800 (PST)
In-Reply-To: <41F14E59.10003 AT metalab.unc.edu>
References: <001b01c4fd59$e77ecca0$0100a8c0@PACKARDBELLXP>      
<41ED294D.4010803 AT metalab.unc.edu>      
<65ABF1C2-6973-11D9-8917-000A95BD16CE AT lbl.gov>  
<41ED47BE.2090901 AT metalab.unc.edu>
        <41ED4BAB.8060705 AT metalab.unc.edu>
        <41ED4D2A.5010506 AT metalab.unc.edu>
        <EDFF800F-697A-11D9-8917-000A95BD16CE AT lbl.gov>
        <62B9DD6C-69E8-11D9-8917-000A95BD16CE AT lbl.gov>
        <D1121DB3-6BDB-11D9-B675-000A95BD16CE AT lbl.gov>
        <41F14E59.10003 AT metalab.unc.edu>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <2B173E25-6BE1-11D9-B675-000A95BD16CE AT lbl.gov>
Content-Transfer-Encoding: 7bit
From: Wolfgang Hoschek <whoschek AT lbl.gov>
Subject: Re: [XOM-interest] Nux 1.0 rc2 problem
Date: Fri, 21 Jan 2005 11:18:01 -0800
To: Elliotte Harold <elharo AT metalab.unc.edu>
X-Mailer: Apple Mail (2.619)
Cc: xom-interest AT lists.ibiblio.org
X-BeenThere: xom-interest AT lists.ibiblio.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: xom-interest.lists.ibiblio.org
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
        <mailto:xom-interest-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/xom-interest>
List-Post: <mailto:xom-interest AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
        <mailto:xom-interest-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Jan 2005 19:18:06 -0000


> Wolfgang Hoschek wrote:
>
>> I'd appreciate it very much if XOM had no hard dependency on Jaxen. 
>> The  easy fix below requires no more than 5 minutes of work and makes 
>> no  changes to the public API at all. Any particular reason that's 
>> not  being done?
>
> There will be a hard dependency on some XPath engine. Possibly in the 
> future that engine will change. I plan to explore SAXON 6.5.3, 
> especially if I can figure out how to fix the bugs in its XSLT support 
> so I could dump Xalan. But XPath support is only going to get more 
> deeply tied into XOM as 1.1 moves forward (i.e. it is likely other 
> methods are going to start depending on the correct operation of 
> Node.query()), so I'm not inclined to pull Jaxen out unless I've got a 
> replacement.

That's not what I ment. What I'd like is XOM not to fail for programs 
that do not directly or indirectly call Node.query(). That's all, and 
the fix does precisely that, by simply and slightly delaying the 
necessary imports. If query() is called and there's no engine jar on 
the classpath it should fail as it does, of course. That's what I mean 
by hard vs. soft dependency.

If a user doesn't call XOM XSLT or call the NFC normalizer he/she 
doesn't need the relevant jars either.

The way it stands one cannot even something as basic as

        System.out.println(new Element("foo").toXML());

without having the XPath engine jar on the classpath!!!

Wolfgang.