Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Nux 1.0 rc2 problem

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Nils_Kilden-Pedersen AT Countrywide.Com
  • To: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] Nux 1.0 rc2 problem
  • Date: Fri, 21 Jan 2005 11:00:39 -0800

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.





Archive powered by MHonArc 2.6.24.

Top of Page