You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Petr Kuzel <Pe...@sun.com> on 2001/09/21 18:31:50 UTC
XNI overlook
Hello,
I just scanned XNI interfaces to find out what is new and
found following issues:
- XMLAttributes.getName(int,QName)
it is odd, supported by JavaDoc talking about setting QName
- XMLAttributes.addAttribute(QName, String, String)
does not specify that the value is non-normalized (I suppose so)
also does not specify isSpecified() state after addition
- XMLAttributes.setValue(String)
probably as a side effect replaces non-normalized value
- XMLDocumentFragmentHandler.emptyElement(QName, XMLAttributes)
it is missing
- should not XMLDocumentHandler be derived from XMLDocumentFragmentHandler?
of both be derived from a new XMLContentHandler interface?
- I still miss definition of call order i.e. requirement for
proper nesting of startXXX() and endXXX() events so it would
be guaranteed that handler can use single stack for holding context
- startEntity(String,...) name can start with
'%' denoting parameter entity
'#' denoting character entity ref
- could be introduced XNIEntityIOException that
should be propagated if a component gets IOException
while scanning some external entity, so it would in
fact convert fatal error (IOException is handled even
more strict than fatal error) to error. Open issue
what to do with pipeline components, they probably
cannot rollback to state prior entity entering.
Comment welcome
Cc.
--
<address>
<a href="mailto:pkuzel@sun.com">Petr Kuzel</a> at Sun Microsystems
: <a href="http://xml.netbeans.org/">XML module</a> and
: <a href="http://jini.netbeans.org/">Jini</a> developer.</address>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: XNI overlook
Posted by Andy Clark <an...@apache.org>.
Petr Kuzel wrote:
> > > - XMLAttributes.getName(int,QName)
> [...]
>
> I did not have nothing against convenience methods in the interface.
> There is just overlook that getName() actually sets one.
This was so the caller provided the object that gets filled
in by the getName call. In this way I avoid returning the
object actually holding the data which would allow the code
to change the values "behind my back"; and also avoid
creating new objects to prevent the first case.
But, in the end, it may be cleaner to remove these and just
have setters/getters for the individual values.
> E.g.: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2213
Okay, I'll look at this.
> > > - startEntity(String,...) name can start with
> > > '%' denoting parameter entity
> > > '#' denoting character entity ref
> > [...]
>
> Right, if application enables it then it must be aware of
> consequences (i.e. proper handling of entity refs starting with '#').
Since it's not a default feature, then this should be
documented where the feature is documented and probably
not in the XNI javadoc.
--
Andy Clark * IBM, TRL - Japan * andyc@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: XNI overlook
Posted by Petr Kuzel <Pe...@sun.com>.
Andy Clark wrote:
>
> Petr Kuzel wrote:
> > - XMLAttributes.getName(int,QName)
>
> I added set/getName(int,QName) for convenience. I have no
> problem with removing them if we then add the appropriate
> set methods for the various parts of the qualified name.
I did not have nothing against convenience methods in the interface.
There is just overlook that getName() actually sets one.
Now I am not sure if the interface should contain convenience
methods (The only pros I can see it is that a direct implementation
may be faster than utility wrapper class. It similar to removed
entity refs convenience methods.).
[snip]
great!
[snip]
>
> > - I still miss definition of call order i.e. requirement for
> > proper nesting of startXXX() and endXXX() events so it would
> > be guaranteed that handler can use single stack for holding context
>
> Which call order are you referring to?
E.g.: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2213
> > - startEntity(String,...) name can start with
> > '%' denoting parameter entity
> > '#' denoting character entity ref
>
> The XNI javadoc details how an XNI-compliant component is
> required to behave. However, there is no requirement that
> an XNI parser be able to mark the start and end of character
> references. The Xerces2 reference implementation can report
> this by setting a feature but it's not on by default.
Right, if application enables it then it must be aware of
consequences (i.e. proper handling of entity refs starting with '#').
> > - could be introduced XNIEntityIOException that
> > should be propagated if a component gets IOException
> > while scanning some external entity, so it would in
> > fact convert fatal error (IOException is handled even
> > more strict than fatal error) to error. Open issue
> > what to do with pipeline components, they probably
> > cannot rollback to state prior entity entering.
>
> Hmmm... I need to think about this more.
>
> Thanks for the comments. If you find any more deficiencies
> in the javadoc (or accompanying docs in the "XNI Manual"),
> feel free to attach patches to your post.
Sometimes I am simply lazy.
Cc.
--
<address>
<a href="mailto:pkuzel@sun.com">Petr Kuzel</a> at Sun Microsystems
: <a href="http://xml.netbeans.org/">XML module</a> and
: <a href="http://jini.netbeans.org/">Jini</a> developer.</address>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: XNI overlook
Posted by Andy Clark <an...@apache.org>.
Petr Kuzel wrote:
> - XMLAttributes.getName(int,QName)
I added set/getName(int,QName) for convenience. I have no
problem with removing them if we then add the appropriate
set methods for the various parts of the qualified name.
> - XMLAttributes.addAttribute(QName, String, String)
> - XMLAttributes.setValue(String)
I updated the javadoc (and implementation) to be more
explicit about the behavior of implementing classes.
> - XMLDocumentFragmentHandler.emptyElement(QName, XMLAttributes)
Added.
> - should not XMLDocumentHandler be derived from XMLDocumentFragmentHandler?
> of both be derived from a new XMLContentHandler interface?
I'm not quite sure on this one. Yes, they share many of
the same methods. However, it doesn't make much sense for
a document handler to implement methods like start/
endDocumentFragment. And it seemed like a waste to add
another base interface just to separate the common methods.
> - I still miss definition of call order i.e. requirement for
> proper nesting of startXXX() and endXXX() events so it would
> be guaranteed that handler can use single stack for holding context
Which call order are you referring to?
> - startEntity(String,...) name can start with
> '%' denoting parameter entity
> '#' denoting character entity ref
The XNI javadoc details how an XNI-compliant component is
required to behave. However, there is no requirement that
an XNI parser be able to mark the start and end of character
references. The Xerces2 reference implementation can report
this by setting a feature but it's not on by default.
> - could be introduced XNIEntityIOException that
> should be propagated if a component gets IOException
> while scanning some external entity, so it would in
> fact convert fatal error (IOException is handled even
> more strict than fatal error) to error. Open issue
> what to do with pipeline components, they probably
> cannot rollback to state prior entity entering.
Hmmm... I need to think about this more.
Thanks for the comments. If you find any more deficiencies
in the javadoc (or accompanying docs in the "XNI Manual"),
feel free to attach patches to your post.
--
Andy Clark * IBM, TRL - Japan * andyc@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org