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]
