Neil,
I'd rather have it in than out. Otherwise things aren't consistent and I
know I'll be changing it later. So we might as well put it in now so
that the API doesn't have to change down the road.
-AndyC
-------- Message d'origine--------
De: [EMAIL PROTECTED]
Date: lun. 28/01/2002 13:45
À: [EMAIL PROTECTED]
Cc:
Objet: RE : [Xerces2] Missing API Changes
Hi Andy,
Yes, I think the literal value should go down the pipeline, but
I don't see
why the expanded value needs to. I agree the expandSystemId
method should
acquire a new home though.
Is this something you can live without, or is this a must-have
for you?
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]> 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]
<<winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
