Re: [XNI] Remaining Issues

Another solution: Define a read-only interface. Derive a read/write interface. Implement the latter. Tell folks that for public API purposes, they should generally use the former, to guard against stepping on their fingers. (Or make the write calls a separate interface and have the concrete cla

Re: [XNI] Remaining Issues

You know, I guess I am not sure what the big deal is...  We pass objects with read/write interfaces on them around all the time to code that we don't expect to modify them and we don't consider them all to be inherently broken.  What is so special about this case ? -Glenn

Re: [XNI] Remaining Issues

Hi Andy, Option 2 seems to be the way to go. The trouble with 1. is that we often have to do things like absolutize URI's. For instance, when processing a schema, we'll often be presented with a relative URI in an ; to present it to SAX, if for no other reason, we need to absolutize it. So the

Re: [XNI] Remaining Issues

[EMAIL PROTECTED] wrote: Well, the consensus between Sandy, Lisa and I is that (a) we kinda wish this hadn't come up at all, but now that we've gone this far, (b) go ahead and change it; we'll slip the release until Monday. This'll give a weekend to run tests and make sure no subtle bugs got intr

Re: xml.apache.org refactoring #1 - expansion of PMC

One more thing...   Per Dirk's message earlier, the people on the PMC will be the default contacts for the ASF wide security effort unless your project specifically designates a security contact.   Ted - Original Message - From: Ted Leung To: [EMAIL PROTECTED] ; [EMAIL P

PMC representation

Hi folks,   I think you've seen my note on refactoring the XML PMC.   I've been trying to look after Xerces related stuff on the PMC, but I think it would be better for someone else(s) to take on this responsibility.  I think that the best solution for would for us to elect 2 people to be ou

xml.apache.org refactoring #1 - expansion of PMC

As you are no doubt aware, the ASF board has approved two new PMC's: one for Web Services (to include Axis, SOAP, XML-RPC, and XML-Security), and one for Cocoon.   In keeping with the proposal that I made last week, I'd like each of the remaining subprojects to elect 1 or 2 persons as they se

Re: [XNI] Remaining Issues

Hi Andy, Well, the consensus between Sandy, Lisa and I is that (a) we kinda wish this hadn't come up at all, but now that we've gone this far, (b) go ahead and change it; we'll slip the release until Monday. This'll give a weekend to run tests and make sure no subtle bugs got introduced. Wonder

Re: [XNI] Remaining Issues

Andy Clark wrote: [EMAIL PROTECTED] wrote: Neither I nor Sandy feel sufficiently strongly about the matter of the XMLLocator setters to contest it. Since you want it changed, are you in a position to change it? Okay, I've made the change. Crap. Late last night I realized that there is a prob

Re: [XNI] Remaining Issues

On Thursday, 01/23/2003 at 02:18 PST, Andy Clark <[EMAIL PROTECTED]> wrote: > Joseph Kesselman wrote: > > That'd work, I guess. Though I don't quite see why this wouldn't want to > > be part of the basic pipeline design. > > Do you have any specific interface ideas? I did, and I *think* I advanc

DO NOT REPLY [Bug 16387] New: - Problems with CDATA Sections

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu