You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Aleksander Slominski <as...@cs.indiana.edu> on 2002/12/10 06:40:42 UTC

XNI: best startegy to move from start/endPrefixMapping

hi,

i have code (PullParser2 and XPP3) that relies on start/endPrefixMapping 
and to be backward compatible i want to keep it.

 however based on reading of release notes 
(http://xml.apache.org/xerces2-j/releases.html) i am not sure if in 
future those call may not be used (as they are now deprecated ...)

what is the best strategy to deal with it? for example should i call 
start/endPrefixMapping manually from start/endElement but how can i 
detect that in future Xerces2 XNI will or will not  call for me 
start/endPrefixMapping? how to detect what version of XNI will use 
require use of NamespaceContext in future (and will not call my 
start/endPrefixMapping)? was NamespaceContext class available in all 
versions of Xerces2 (i have never used it before) - if not how i can 
write/implement XMLDocumentHandler that will  have method with 
NamespaceContext so it will fail to work with old X2 (should i maybe 
make a copy of org.apache.xerces.xni.NamespaceContext and bundle it with 
XPP2/XPP3 code?)

it is possible at all to have backward compatibility with older Xerces 2 
(older versions of X2 are still used in many projects) or i should just 
give up on it and after checking X2 verion fail fast by throwing 
exception to user?

i will appreciate any info regarding this issue.

thanks,

alek

-- 
The ancestor of every action is a thought. - Ralph Waldo Emerson 



---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org


Re: XNI: best startegy to move from start/endPrefixMapping

Posted by Andy Clark <an...@apache.org>.
Aleksander Slominski wrote:
> i have code (PullParser2 and XPP3) that relies on start/endPrefixMapping 
> and to be backward compatible i want to keep it.
> 
> however based on reading of release notes 
> (http://xml.apache.org/xerces2-j/releases.html) i am not sure if in 
> future those call may not be used (as they are now deprecated ...)
> 
> what is the best strategy to deal with it? 

I had the same problem updating my NekoPull[1] API to
be able to use all versions of Xerces2. In the end it
didn't turn out to be that hard to fix. The hard part
was handling changed method signatures -- needed Java
reflection for that.

You can look at my code to see how I solved this
problem. But here's the basic premise: there's a new
startDocument method that passes the NamespaceContext
object at the beginning of the document. Implement
that method and keep a reference to the object. Then,
in the start (and empty) element method callback(s),
check for a non-null value for the namespace context.
If it exists, then ask it for the count of declared
prefixes, query the prefixes and URIs, and then call
your existing start/endPrefixMapping methods.

Does that make sense?

> it is possible at all to have backward compatibility with older Xerces 2 
> (older versions of X2 are still used in many projects) or i should just 
> give up on it and after checking X2 verion fail fast by throwing 
> exception to user?

Please be aware that we are currently discussing
changing the namespace context interface. (See the
posts from Elena about this subject.) Now that we
have learned more about using the new framework,
we feel that certain API changes are required and
this is one of the changes.

So once we've concluded our discussions and made
the changes, we plan on versioning the XNI frame-
work. Then, subsequent changes will go into future
versions of the API.

[1] http://www.apache.org/~andyc/neko/doc/pull/index.html

-- 
Andy Clark * andyc@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org