Hi Lionel: > >Yes actually I think you're right. I just hope that the QName java class >won't be 'final'.
I agree with you that this can't be final. And all the indications from the JAXP 1.3 EG are that it won't be final. Regards -Ramesh I just have to do is to rely on the expression factory >to creates/gets a qname. >Thanks! > >Lionel Villard >IBM T.J Watson > > > > > >Ramesh Mandava <[EMAIL PROTECTED]> >07/25/2003 02:25 PM >Please respond to xalan-dev > > To: [EMAIL PROTECTED] > cc: > Subject: Re: XPath API issues and plans > > >Hi Lionel: > > >>Hi all, >> I want to give you an overall of the remaining issues that need >to >> >>be addressed to fulfill the XPath API requirements (in xstl20 branch >under >> >>the xpath_rwapi directory). One of these requirements is to allow several > >>applications to implement and/or reuse efficiently the XPath API and many > >>problems need to be solved in order to reach it. Here the list of these >>issues and also more general tasks to be done: >> >>XPath public API: >> >>- namespace/qname resolver : most of applications use a qname manager for > >>example to share the same qname pool throughout their application. >>Currently the public XPath API relies on the JAXP QName definition. I >want >> >>to remove this dependency and to define a QName interface that >>applications can implement within their QName manager. > > Can we get away with defining another QName interface. If needed we can >have, >JAXP QName ( supposed to be the standard ) wrapped inside the QName >Manager. > As the main aim of JAXP QName is to standardize QName, our adaption >would help >that goal. > > Regards > -Ramesh > > >
