Hi Neil, > So I will make the change. This will delay the release for a while, but if > I don't see any regressions we should still be able to push forward this > afternoon.
i hope same.. we all are waiting for it to happen. Hopefully be it today :-) Best Regards, Neeraj B. Sun Microsystems, inc. > > Neeraj Bajaj <[EMAIL PROTECTED]> on 01/29/2002 04:08:12 PM > > Please respond to [EMAIL PROTECTED] > > To: [EMAIL PROTECTED] > cc: > Subject: Re: RE : [Xerces2] Missing API Changes > > > Hi Neil, > > > Can you cite the place in SAX where we're required to expose expanded > > systemId's to the application w.r.t. notations and unparsed entities? My > > reading of the DTDHandler methods leads me strongly to believe that it's > > the literal value that should be returned, not the expanded value. > > http://www.saxproject.org/apidoc/org/xml/sax/DTDHandler.html#notationDecl(java.l > > ang.String, java.lang.String, java.lang.String) > > "it says that if a system identifier is present, and it is a URL, the SAX > parser > must resolve it fullly before passing it to the application through this > event" > I think this is in the same terms as > LocatorImpl,SaxparseException for > which we actually send the expanded system id before passing it to the > application, but as of now we are not doing it for notationDecl() and > unparsedEntityDecl(). And i think we need to do it so that we comply with > SAX > and systemId value passed is as expected by the application. > > > What's your view ? > > regards, > > -- > Neeraj B. > Sun Microsystems, inc. > > > > > > > > > Neeraj Bajaj <[EMAIL PROTECTED]> on 01/29/2002 02:45:47 PM > > > > Please respond to [EMAIL PROTECTED] > > > > To: [EMAIL PROTECTED] > > cc: > > Subject: Re: RE : [Xerces2] Missing API Changes > > > > > > Hi Neil, > > > > > Yes, I think the literal value should go down the pipeline, but I don't > > see > > > why the expanded value needs to. > > > > We need to expand 'systemid' for unparsedEntityDecl, > > notationDecl as of > > right now we are not doing it but SAX requires the parser to resolve it > > fully. > > I also agree with Andy that we should use > > XMLResourceIdentifier > > wherever it makes sense and be consistent across XNI. > > > > regards, > > > > Neeraj B. > > Sun Microsystems, inc. > > > > > > > > > > > > > "Andy Clark" <[EMAIL PROTECTED]> on 01/28/2002 01:49:47 PM > > > > > > Please respond to [EMAIL PROTECTED] > > > > > > To: <[EMAIL PROTECTED]> > > > cc: > > > Subject: RE�: [Xerces2] Missing API Changes > > > > > > > > > Neil, > > > > > > You don't think it's important to have the literal system id for the > > > externalEntityDecl or unparsedEntityDecl? I do. It should be expanded > > > and passed along. Currently the code that does that is in the > > > impl.XMLEntityManager class. But it's just a static method and I think > > > perhaps we should have a xerces.util class for this of some kind. > > > > > > -AndyC > > > > > > -------- Message d'origine-------- > > > De: [EMAIL PROTECTED] > > > Date: lun. 28/01/2002 13:21 > > > �: [EMAIL PROTECTED] > > > Cc: > > > Objet: Re: [Xerces2] Missing API Changes > > > > > > > > > > > > Hi Andy, > > > > > > I'll undertake to make change #5 you suggest--since it's > just > > > adding a > > > constructor there won't be much propagation necessary! :-) > > > > > > I'm not sure I agree with change #3 though; in these > > situations > > > I don't > > > think it ever makes sense to have the literal system Id > > > expanded, since > > > there won't be any external decls referenced from these > > > entities. That's > > > why I left these callbacks out of the big changes--save > > > ourselves an URI > > > expansion where we can... > > > > > > Besides, this change *would* require a fair bit of > > propagation, > > > to make > > > sure the XMLResourceIdentifiers were being initialized > > correctly > > > etc.; it's > > > one I'd like to avoid this late in the game... > > > > > > what do you think? > > > 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]> on 01/28/2002 01:14:07 PM > > > > > > Please respond to [EMAIL PROTECTED] > > > > > > To: <[EMAIL PROTECTED]> > > > cc: > > > Subject: [Xerces2] Missing API Changes > > > > > > > > > With the impending release of Xerces 2.0.0, I'm seeing a > bunch > > > of little > > > things that need to be fixed in XNI and the implementation. > > For > > > example: > > > > > > 1) xni/Augmentations > > > > > > This interface is missing a way to iterate over items in the > > > augmentations list. To keep naming consistent, I would > suggest > > > the > > > following: > > > > > > int getKeyCount() > > > String getKeyAt(int index) > > > > > > 2) xni/XMLAttributes > > > > > > Missing a getAugmentations method. Every other piece of > > > information > > > associated to an attribute (e.g. returning an attribute's > > type) > > > has > > > three methods: one that takes the attribute index as a > > > parameter; one > > > with a String qname; and one with a String uri and > localpart. > > > The > > > augmentations information is missing the qname method. So > > either > > > add it > > > or only put a get method with the index parameter like > > > isSpecified and > > > getNonNormalizedValue. > > > > > > 3) xni/XMLDTDHandler > > > > > > There were a bunch of changes to go through the code and use > > the > > > new > > > XMLResourceIdentifier interface where it made sense. (Thanks > > for > > > applying a bunch of my changes, Neil.) But there's still > some > > > more > > > places where it should be used to be consistent. For > example, > > > the > > > externalEntityDecl method still passes three separate String > > > parameters > > > instead of the new interface. We should be consistent. Same > > with > > > the > > > unparseEntityDecl method. > > > > > > 4) xni/parser/XMLConfigurationException > > > > > > The constants that distinguish between not recognized and > not > > > supported > > > are defined to be the same value! Oops! Probably my fault > when > > I > > > first > > > added this interface but I don't have any way of doing > updates > > > at the > > > moment so I would appreciate if someone made this change for > > me. > > > > > > 5) xni/parser/XMLInputSource > > > > > > Since we added the XMLResourceIdentifier interface, it might > > be > > > nice to > > > use this in the constructor and/or add a method to all of > the > > > publicId, > > > systemId, etc. values to be set at once by passing an > > > XMLResourceIdentifier. > > > > > > 6) Copyright notices > > > > > > All of the source files should be updated to include 2002 in > > the > > > copyright years in the Apache License at the top of the > source > > > file. > > > > > > 7) Version information > > > > > > All of the source files should be updated to remove the > > > "@version Stubs > > > generated by DesignDoc ..." line from the class/interface > > > comment. > > > > > > 8) Implementation > > > > > > It goes without saying that all of the XNI changes I have > > > suggested need > > > to propagate throughout the source code. But I don't have > the > > > time or > > > resources at this time to check to make sure that there > aren't > > > additional problems in the implementation. I don't think > that > > > this is > > > too bad, though, as long as we are still passing all of the > > > comformance > > > tests. I am just concerned with getting XNI into a good > solid > > > state > > > before the release. If we have to change it in the future, > > fine, > > > but > > > let's try not to -- I think our users will be happier if we > > > don't need > > > to change anything on them in the future. :) > > > > > > Okay, that's all for now. I'll be posting at least one more > > > message to > > > the list soon. Type at you later... > > > > > > -AndyC > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > > > (See attached file: winmail.dat) > > > --------------------------------------------------------------------- > > > 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] > > > > > > > > > --------------------------------------------------------------------- > 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]
