[ 
http://nagoya.apache.org/jira/browse/XALANJ-757?page=comments#action_56823 ]
     
Joe Kesselman commented on XALANJ-757:
--------------------------------------

A "pseudo-XPath" generator written in XSLT was published in part 2 of my my 
DeveloperWorks article on styling stylesheets (plug: 
http://www-106.ibm.com/developerworks/xml/library/x-styless2/)

It didn't handle the namespace issue, for reasons discussed there (basically, 
XPath syntax limitations make writing portable namespace-appropriate XPaths 
rather difficult.) It could be patched to do so by writing the paths to 
namespaced nodes as element types with predicates that do the actual match of 
namespace and localname; human-readability of the resulting XPaths would suffer 
but correct function would be achieved.

The same basic logic, obviously, could be rewritten in Java or C++ to operate 
directly on a DOM. That's be a reasonable utility function to offer for the 
convenience of Apache developers... but might want to go in in the XML-Commons 
package rather than in Xalan or Xerces.

> Add a DOM-node XPath generator utility
> --------------------------------------
>
>          Key: XALANJ-757
>          URL: http://nagoya.apache.org/jira/browse/XALANJ-757
>      Project: XalanJ2
>         Type: New Feature
>   Components: XPath
>     Versions: CurrentCVS
>  Environment: Operating System: All
> Platform: All
>     Reporter: Joe Kesselman

>
> See mailing list archives for past discussion. A simple 
> /x:foo[1]/y:bar[3]/x:bax[2] path (with associated namespace context) is 
> almost 
> trivial to generate, so there isn't a strong need for Xalan to provide this 
> operation... but it would be a nice convenience to offer.
> Handling the namespaces properly is the most complicated part.
> If we wanted to get fancy, we could take it up a notch and generate paths 
> from 
> one node to another rather than always from root. But at that point I believe 
> the variability of XPaths, and questions about which choices will be most 
> robust 
> under actual use of this particular document, become large enough issues that 
> we 
> should tell the user to code their own.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to