commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 32360] - [jxpath] Default Namespace not handled correctly
Date Tue, 01 Feb 2005 16:16:01 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=32360>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32360





------- Additional Comments From edwin@emaxx.nl  2005-02-01 17:16 -------
We're having similar problems as Richard has. Especially in automation the   
current solution does not work well.   
   
The problem seems to be related to the nature of the binding. Right now the   
binding of prefix and namespace is done on the context and not on the query.    
   
This makes it impossible to distinguish between:   
   
a. the namespace bindings of the document itself, and   
b. the namespace bindings of context of the document.   
   
I will even go so far as to say the namespace binding solution, proposed in the   
XPath specification is too thin. The reasons in favor for the XPath solutions   
are clear though: uncluttered means of querying (binding for every XPath query   
would be too combersome).   
   
Nevertheless, the specs are how they are and we can't change much about that.   
   
The situation with JXPath is different than XPath. JXPath has the fortune of   
being able to access the same (set of) binding(s) multiple times without much   
clutter (by means of references). This makes at least a specific implementation  
of the query solver (through factory pattern) in my oppinion worthwhile.  
  
Especially in the eye of automation (regarding the creation of automatic  
bindings/matchers based on xsd analysis), this is a worthwhile feature. 
   
(In reply to comment #3)   
<cut> 
> If I declare   
>   context.registerNamespace(null, "http://test")   
>    
> and then try:   
>   context.getValue("/parent/test/child-element")   
>    
> I get nothing, because "parent" does not have "http://test" as its namespace.   
 
Yes, this would be a problem. Nevertheless, if I would create a subcontext 
(which is more than logical, since it is clearly in another namespace), then I 
can make an addditional binding. 
 
Thanks and regards, 
 
Edwin   

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message