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 2002/01/09 14:08:30 UTC
XNI Augmentations
Hello,
recent version of XNI contains many XMLDocumentHandler and XMLDTDHandler
methods with the same name and parameters except the Augmentations
parameter. Should not we add Augmentations parameter also to
XMLDTDHandler callbacks? (just curious)
With exception of XMLDTDHandler.characters() that could be renamed,
as somebody suggested, to ignoredText().
Again, why XMLAttributes.setValue() overwrites also non-normalized
value? (causes trouble)
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 Augmentations
Posted by Petr Kuzel <Pe...@sun.com>.
Andy Clark wrote:
>
> Petr Kuzel wrote:
> > Those that are hidden by DTD scanner i.e. parameter entities
> > in markup. As I said I can live without it, as I will need to
> > rewrite scanner. I can create a side channel, but then appears
> > problems with synchronization.
>
> It's certainly open to discussion. I thought at the beginning
> that *all* of the XNI handlers should be modified to allow
> augmentations to be passed along. So I would vote to add the
> augmentations.
Cool, looking forward it.
> > > Okay. Do you want to submit a patch to fix this problem?
> >
> > Already done, even twice. It's really tiny one. > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5745
>
> No, I meant going through *all* of the source every place
> that the method is called to ensure that the parser's
> behavior remains consistent. That is the patch I'm looking
> for. :)
I must admit it sounds like genetics programing, I made
"random" program mutation and tested behavior. It works
better so I let it live :-).
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 Augmentations
Posted by Andy Clark <an...@apache.org>.
Petr Kuzel wrote:
> Those that are hidden by DTD scanner i.e. parameter entities
> in markup. As I said I can live without it, as I will need to
> rewrite scanner. I can create a side channel, but then appears
> problems with synchronization.
It's certainly open to discussion. I thought at the beginning
that *all* of the XNI handlers should be modified to allow
augmentations to be passed along. So I would vote to add the
augmentations.
> > Okay. Do you want to submit a patch to fix this problem?
>
> Already done, even twice. It's really tiny one. > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5745
No, I meant going through *all* of the source every place
that the method is called to ensure that the parser's
behavior remains consistent. That is the patch I'm looking
for. :)
--
Andy Clark * 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 Augmentations
Posted by Petr Kuzel <Pe...@sun.com>.
Andy Clark wrote:
>
> Petr Kuzel wrote:
> > Yes, parameter entities. My scanner can then generate an additional info
> > without a need for private interface.
>
> What extra information. I don't see a problem with adding
> augmentations to the other handlers -- I'm just curious as
> to what additional DTD information you'd like to pass along.
Those that are hidden by DTD scanner i.e. parameter entities
in markup. As I said I can live without it, as I will need to
rewrite scanner. I can create a side channel, but then appears
problems with synchronization.
> > Once in history I even thought about a method augment(Augmentations)
> > that could be called prior particular handler callback if needed.
> > Later pipe components must propagate it in same manner. It is alternative
> > approach to the extra parameter. Unfortunately it may complicate logic.
>
> This is a bad idea because there's no way to guarantee that
> the two separate callbacks can be associated together. Since
> the parser is configured as a pipeline of separate components,
> there may be components later in the pipeline that add or
> remove method calls. Then the augmentations passed separately
> are no longer in sync.
That is right, I called it complicated logic :-).
> > > public void setValues(String value, String nonNormalizedValue);
> >
> > It is an interface so I would keep method count as low as possible.
> > -1
>
> Okay. Do you want to submit a patch to fix this problem?
Already done, even twice. It's really tiny one. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5745
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 Augmentations
Posted by Andy Clark <an...@apache.org>.
Petr Kuzel wrote:
> Yes, parameter entities. My scanner can then generate an additional info
> without a need for private interface.
What extra information. I don't see a problem with adding
augmentations to the other handlers -- I'm just curious as
to what additional DTD information you'd like to pass along.
> Once in history I even thought about a method augment(Augmentations)
> that could be called prior particular handler callback if needed.
> Later pipe components must propagate it in same manner. It is alternative
> approach to the extra parameter. Unfortunately it may complicate logic.
This is a bad idea because there's no way to guarantee that
the two separate callbacks can be associated together. Since
the parser is configured as a pipeline of separate components,
there may be components later in the pipeline that add or
remove method calls. Then the augmentations passed separately
are no longer in sync.
> > public void setValues(String value, String nonNormalizedValue);
>
> It is an interface so I would keep method count as low as possible.
> -1
Okay. Do you want to submit a patch to fix this problem?
--
Andy Clark * 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 Augmentations
Posted by Petr Kuzel <Pe...@sun.com>.
Andy Clark wrote:
>
> Petr Kuzel wrote:
> > recent version of XNI contains many XMLDocumentHandler and XMLDTDHandler
> > methods with the same name and parameters except the Augmentations
> > parameter. Should not we add Augmentations parameter also to
> > XMLDTDHandler callbacks? (just curious)
>
> I guess the reasoning is just that we didn't see a need to
> ever add arbitrary information to the DTD declarations and
> information. Do you have any use cases that require this
> change?
Yes, parameter entities. My scanner can then generate an additional info
without a need for private interface.
Once in history I even thought about a method augment(Augmentations)
that could be called prior particular handler callback if needed.
Later pipe components must propagate it in same manner. It is alternative
approach to the extra parameter. Unfortunately it may complicate logic.
> > With exception of XMLDTDHandler.characters() that could be renamed,
> > as somebody suggested, to ignoredText().
>
> Yeah, this name has bothered me for quite some time. I'm in
> favor of changing the name if others agree.
>
> > Again, why XMLAttributes.setValue() overwrites also non-normalized
> > value? (causes trouble)
>
> Good point. This should change. Also, what do people think
> about adding the following method to XMLAttributes?
>
> public void setValues(String value, String nonNormalizedValue);
It is an interface so I would keep method count as low as possible.
-1
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 Augmentations
Posted by Andy Clark <an...@apache.org>.
Petr Kuzel wrote:
> recent version of XNI contains many XMLDocumentHandler and XMLDTDHandler
> methods with the same name and parameters except the Augmentations
> parameter. Should not we add Augmentations parameter also to
> XMLDTDHandler callbacks? (just curious)
I guess the reasoning is just that we didn't see a need to
ever add arbitrary information to the DTD declarations and
information. Do you have any use cases that require this
change?
> With exception of XMLDTDHandler.characters() that could be renamed,
> as somebody suggested, to ignoredText().
Yeah, this name has bothered me for quite some time. I'm in
favor of changing the name if others agree.
> Again, why XMLAttributes.setValue() overwrites also non-normalized
> value? (causes trouble)
Good point. This should change. Also, what do people think
about adding the following method to XMLAttributes?
public void setValues(String value, String nonNormalizedValue);
--
Andy Clark * 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