From commons-user-return-11705-apmail-jakarta-commons-user-archive=jakarta.apache.org@jakarta.apache.org Wed Apr 20 17:50:54 2005 Return-Path: Delivered-To: apmail-jakarta-commons-user-archive@www.apache.org Received: (qmail 8586 invoked from network); 20 Apr 2005 17:50:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 20 Apr 2005 17:50:54 -0000 Received: (qmail 19054 invoked by uid 500); 20 Apr 2005 17:50:49 -0000 Delivered-To: apmail-jakarta-commons-user-archive@jakarta.apache.org Received: (qmail 18990 invoked by uid 500); 20 Apr 2005 17:50:48 -0000 Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Users List" Reply-To: "Jakarta Commons Users List" Delivered-To: mailing list commons-user@jakarta.apache.org Received: (qmail 18970 invoked by uid 99); 20 Apr 2005 17:50:48 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=RCVD_BY_IP X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: domain of mnestler@gmail.com designates 64.233.184.202 as permitted sender) Received: from wproxy.gmail.com (HELO wproxy.gmail.com) (64.233.184.202) by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 20 Apr 2005 10:50:48 -0700 Received: by wproxy.gmail.com with SMTP id 58so243332wri for ; Wed, 20 Apr 2005 10:50:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VefAN0eCcyMVEwJun6TELGvW/YzZZcWS2v8NJpdIGN2zaunb0keBmMx5VE4c3m65i6XPxUlp4le8XVf+HNvevT1qKn19jyzmJwe7Re4Id6FXvY0KTjHbvh3aXQIEda8BXcP29LD2BjYrPT2CHggoJ5iwXtQ3EGXr4+kiEhhpgDY= Received: by 10.54.46.52 with SMTP id t52mr6650014wrt; Wed, 20 Apr 2005 10:50:39 -0700 (PDT) Received: by 10.54.56.63 with HTTP; Wed, 20 Apr 2005 10:50:39 -0700 (PDT) Message-ID: Date: Wed, 20 Apr 2005 10:50:39 -0700 From: Michael Nestler Reply-To: mnestler@jot.com To: commons-user@jakarta.apache.org, Dmitri Plotnikov Subject: Re: [JXPath] Context Namespace-Relative Queries (v1.2) In-Reply-To: <007801c54361$99e1d4d0$0500a8c0@plotnix2500> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <007801c54361$99e1d4d0$0500a8c0@plotnix2500> X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Dmitri, Please see my comments below. On 4/17/05, Dmitri Plotnikov wrote: > Michael, >=20 > You are not the first to raise this issue. See for example the discussio= n > in this bug report: > http://issues.apache.org/bugzilla/show_bug.cgi?id=3D32360 I can understand the frustration. > I think it's time we finally resolve the problem. >=20 > We have come up with three alternative solutions so far: >=20 > 1. Using "null" for namespace prefix. I don't necessarily like the idea = - > it feels atrificial and it blocks access to elements that have no namespa= ce > at all. Right, I don't like it either. > 2. We introduce this new method on JXPathContext: >=20 > context.registerDefaultNamespace(ns); >=20 > Then whenever a name is used without prefix in an XPath, this default > namespace is assumed. This is effectively the same as 1, except that > aestetically this looks better. Unfortunately this solution has the same > problem: you can no longer reference elements that really don't have any > namespace. I agree. =20 > 3. We introduce this other method on JXPathContext: > context.setNamespaceIgnored(ns, boolean) >=20 > This would allow us to register one or multiple namespaces that should be > ignored altogether. Let's say > - you call context.setNamespaceIgnored("abc", true) > - you have a document that looks like this: >=20 > > y > x > >=20 > - and you try to resolve the xpath "//a" >=20 > This path will return both elements: x and y, one because it does not hav= e a > namespace and the other because its namespace is ignored. >=20 > This third option is my favorite. >=20 > What do you think? I think it would be useful and I would certainly make use of this feature. But I don't think it would solve the problem I mentioned in my original email. I am not able to entirely ignore namespaces. My problem is that my root element's namespace is variable (could be XHTML, a custom namespace, or nothing) - but I still want to make sure that the child elements' namespace is the same as the root element's. In other words: I want to distinguish between "the root elements' namespace" and "no namespace" (and "another namespace"). Your option #3 as I understand it would not allow that, right? Can I suggest an option #4? Could JXPathContext (preferrably per default) make the namespace of the root element the default namespace for queries? Then I could execute queries reliably and independent of the actual namespace of the root element, but at the same time ensure that all queried child elements are in the same namespace as the root element. Does this make sense or would this collide with other requirements? To summarize, I really think that your option #3 is the best of 1-3. I would be really happy if JXPath would implement both #4 and #3. -Michael > ----- Original Message ----- > From: "Michael Nestler" > To: > Sent: Thursday, April 07, 2005 1:08 PM > Subject: [JXPath] Context Namespace-Relative Queries (v1.2) >=20 > > Hello, > > > > I recently had to switch from JXPath 1.1 to 1.2 in order to benefit > > from some bug fixes. I am using JDOM 1.0. It appears that JXPath's > > behavior regarding namespaces in JDOM trees changed and became less > > convenient and flexible. > > > > I have documents like this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
pagetypecomment
confHome Page
confTool Bar
> > > > > > The namespace of the root element is variable and might be the XHTML > > namespace, another namespace, or no namespace at all. The table > > structure is always the same, and cell values vary. And I have some > > code that executes the following query: > > > > SAXBuilder sax =3D new SAXBuilder(); > > Document doc =3D sax.build(new StringReader(...); > > Element rootElement =3D doc.getRootElement(); > > JXPathContext ctx =3D JXPathUtil.newContext(rootElement); > > String value =3D ctx.getValue("/table/tr[2]/td[2]"); > > > > This worked fine with JXPath 1.1, but it doesn't work anymore with > > 1.2. The new JXPath version throws an exception: > > > > org.apache.commons.jxpath.JXPathException: No value for xpath: > > /table/tr[2]/td[2] > > at > > org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.getValue(JXPath= ContextReferenceImpl.java:344) > > at > > org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.getValue(JXPath= ContextReferenceImpl.java:280) > > > > Why would this not work, considering that all the DOM nodes live in > > the same namespace - the namespace of the context bean (root element)? > > It appears that I can register the XHTML namespace, but then I have to > > use a prefix for every element name in my query - and it won't work if > > the namespace is not set or is different (that's possible in my app). > > > > Is there a solution to this problem, i.e. is there a way to make > > JXPath interpret the root element's namespace as the default namespace > > requiring no prefix in XPath queries? > > > > Thanks in advance, > > -Michael > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org > > For additional commands, e-mail: commons-user-help@jakarta.apache.org > > > > > > > > >=20 > --------------------------------------------------------------------- To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-user-help@jakarta.apache.org