RE : [Xerces2] Missing API Changes

[Andy Clark <an...@cyberneko.net>]

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: neilg@ca.ibm.com 
	Date: lun. 28/01/2002 13:21 
	À: xerces-j-dev@xml.apache.org 
	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:  neilg@ca.ibm.com
	
	
	
	"Andy Clark" <an...@cyberneko.net> on 01/28/2002 01:14:07 PM
	
	Please respond to xerces-j-dev@xml.apache.org
	
	To:   <xe...@xml.apache.org>
	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: xerces-j-dev-unsubscribe@xml.apache.org
	For additional commands, e-mail:
xerces-j-dev-help@xml.apache.org