You have my +1 too.

Entity resolution is a good example showing why XMLResourceIdentifier
should be read-write. In XMLEntityManager, before calling the entity
resolver, it tries to absolutize the system Id, and sets it back to the
XMLResourceIdentifier. But with it being read-only, sometimes a new
instance of XMLResourceIdentifierImpl needs to be created. This means some
useful information in the original XMLResourceIdentifier might be lost.

Sandy Gao
Software Developer, IBM Canada
(1-905) 413-3255
[EMAIL PROTECTED]



                                                                                       
                                                
                      Neil                                                             
                                                
                      Graham/Toronto/IB        To:       [EMAIL PROTECTED]   
                                                
                      M@IBMCA                  cc:                                     
                                                
                                               Subject:  Re: XNI: making 
NamesapaceContext read/write                                  
                      10/18/2002 12:09                                                 
                                                
                      PM                                                               
                                                
                      Please respond to                                                
                                                
                      xerces-j-dev                                                     
                                                
                                                                                       
                                                
                                                                                       
                                                



Hi all,

+1 to Elena's suggestions.  There are just too many situations where this
is the only elegant solution not to go for the idea.

Cheers,
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone:  905-413-3519, T/L 969-3519
E-mail:  [EMAIL PROTECTED]




|---------+---------------------------->
|         |           Andy Clark       |
|         |           <[EMAIL PROTECTED]|
|         |           >                |
|         |                            |
|         |           10/18/2002 10:13 |
|         |           AM               |
|         |           Please respond to|
|         |           xerces-j-dev     |
|         |                            |
|---------+---------------------------->
  >
---------------------------------------------------------------------------------------------------------------------------------------------|

  |
|
  |       To:       [EMAIL PROTECTED]
|
  |       cc:
|
  |       Subject:  Re: XNI: making NamesapaceContext read/write
|
  |
|
  |
|
  >
---------------------------------------------------------------------------------------------------------------------------------------------|




Elena Litani wrote:
> The following are the only interfaces in the XNI that are read-only:
>
> * NamespaceContext
> * XMLResourceIdentifier
> * XMLLocator
>
> Given that XNI now uses NamespaceContext, instead of
> start/endPrefixMapping, some components in the pipeline need to be able
> to add namespace declarations. Consider, for example, the following
> case:

Yes, this seems like the natural progression. Everything
*else* is read/write so why aren't these interfaces that
you list the same? Since we're trying to round out XNI
by the end of the year and make the final 1.0 changes, I
think that this is worthwhile.

What does everyone else think?

--
Andy Clark * [EMAIL PROTECTED]


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





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





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

Reply via email to