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 Arnaud Le Hors <le...@us.ibm.com> on 2001/03/26 18:53:36 UTC
Re: cvs commit: xml-xerces/java/src/org/apache/xerces/xni/parser
XMLComponent.java XMLParserConfiguration.java
All right,
I checked that in friday night before leaving the office and didn't have
to time to explain. We have a problem that I'm not sure how to address.
Let me get to it now.
> > + * @param check Whether to check if the feature is recognized.
> > [...]
> > - public void setFeature(String featureId, boolean state)
> > + public void setFeature(String featureId, boolean state, boolean check)
> > throws SAXNotRecognizedException, SAXNotSupportedException;
>
> A "check" parameter? Yuck. First of all, this isn't needed
> because the parser configuration knows all of the recognized
> features/properties from the getRecognizedFeatures/Properties
> methods, respectively.
Not true. The problem that the parser is not a component, I wanted to
make it one and you said 'no way, it's not a component it's the parser'.
Because of that the configuration does NOT know what features and
properties the parser recognizes/supports.
Practically speaking that means I have to do something like that for
setFeature:
SAXParser:
check for SAX feature
if known process and send it to the config
else simply forward to the config
Because the config doesn't know about the SAX feature when the parser
sends it one we need the config not to check on it but simply store the
value and forward it to every component. That's what this extra set of
methods is about.
If we make the parser a component. Then the config can query the parser
for what feature/property it recognizes. But unfortunately it doesn't
save us from needing an extra set of methods. Because we'd have
something like that:
SAXParser:
forward setfeature to config
Config:
forward setfeature to every component (including SAXParser)
This leads to an infinite loop unless you use distinct methods!
> Just because you haven't implemented
> those methods yet on the parser components, doesn't mean
> that we need this extra parameter.
On the contrary!! Because I haven't implemeted those methods yet means I
DO need this extra parameter. Just a fact! :-)
> Second, adding this
> parameter breaks the API compatibility with the equivalent
> methods in SAX2's XMLReader interface. I'd like them to
> overlay each other.
It doesn't break anything. The SAX methods are there ALSO.
> > /**
> > + * Returns the state of a feature.
> > + *
> > + * @param featureId The feature identifier.
> > + * @param check Whether to check if the feature is recognized.
> > + *
> > + * @throws SAXNotRecognizedException Thrown if the feature is not
> > + * recognized.
> > + * @throws SAXNotSupportedException Thrown if the feature is not
> > + * supported.
> > + */
> > + public boolean getFeature(String featureId, boolean check)
> > + throws SAXNotRecognizedException, SAXNotSupportedException;
>
> The getFeature/Property method prototypes don't need to be
> explicitly added to the XMLParserConfiguration interface
> because they are already defined on XMLComponentManager,
> which the parser configuration interface extends.
But, as you noticed, there are NOT the same, these have an extra
parameter. :-)
--
Arnaud Le Hors - IBM Cupertino, XML Strategy Group
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: setFeature/Property (was Re: cvs commit:
xml-xerces/java/src/org/apache/xerces/xni/parser XMLComponent.java
XMLParserConfiguration.java)
Posted by Andy Clark <an...@apache.org>.
Ted Leung wrote:
> So let me make sure I get it. We have to re-setup the pipeline every time
> we call parse() right? How is this going to interact with doing stuff like
> reset() on an existing parser? Will we still have to setup the pipeline
> between resets?
Only if the nature of the pipeline is dynamic in the sense
that we don't know what components will be used at creation
time (before setting features/properties and parsing). Even
if the pipeline is created dynamically (via an XML config
file, for example) this is ok as long as it's done before-
hand and isn't changed.
--
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: setFeature/Property (was Re: cvs commit: xml-xerces/java/src/org/apache/xerces/xni/parser XMLComponent.java XMLParserConfiguration.java)
Posted by Ted Leung <tw...@sauria.com>.
----- Original Message -----
From: "Arnaud Le Hors" <le...@us.ibm.com>
To: <xe...@xml.apache.org>
Sent: Tuesday, March 27, 2001 12:30 PM
Subject: setFeature/Property (was Re: cvs commit:
xml-xerces/java/src/org/apache/xerces/xni/parser XMLComponent.java
XMLParserConfiguration.java)
> Andy Clark wrote:
> >
> > Okay, thanks for the clarification. I just sort of freaked when
> > all these changes were made without much reasoning behind it. I
> > feel much better now. :)
>
> The fact you don't know the reasoning behind a change doesn't
> necessarily means there is none. :) I can see how much you trust me
> now... ;)
>
> > > SAXParser:
> > >
> > > check for SAX feature
> > > if known process and send it to the config
> > > else simply forward to the config
> >
> > Okay, so we have the situation where specific parser configs
> > such as DOM or SAX add recognized features to the parser config
> > but the parser is not a component. And if it were, then we have
> > the recursion problem you mentioned.
>
> That's a good summary.
>
> > Simple solution. Add the following methods to the parser
> > configuration:
> >
> > public void addRecognizedFeature(String featureId);
> > public void addRecognizedProperty(String propertyId);
>
> Hmm. If that's what it is then I'd rather make them:
>
> public void addRecognizedFeatures(String[] featureIds);
> public void addRecognizedProperties(String[] propertyIds);
>
> > Then the parser can add the features and properties that it
> > needs to recognize; everything is forwarded to and is managed
> > by the configuration; and you avoid the recursion. Does this
> > solve the problems we're facing? Or are there more?
>
> Kinda. It does solve the problem but it's not optimal. It means that
> even though the SAXParser already recognized the feature/property the
> configuration is going to check on it. My check flag avoids this. But
> I'll admit that this is probably not an area where performance really
> matters.
>
> One other problem with this config stuff (not your proposal) is that to
> allow an application to register its own components through the
> properties (to use instead of the default ones) I have to delay the
> creation of the pipeline until parse() gets called. As opposed to doing
> it at creation time. But this means the configuration object can't
> forward to the components the features and properties that are set
> before calling parse(). I don't have any components yet! Any ideas?
So let me make sure I get it. We have to re-setup the pipeline every time
we call parse() right? How is this going to interact with doing stuff like
reset() on an existing parser? Will we still have to setup the pipeline
between
resets?
Ted
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: setFeature/Property (was Re: cvs commit:
xml-xerces/java/src/org/apache/xerces/xni/parser XMLComponent.java
XMLParserConfiguration.java)
Posted by Andy Clark <an...@apache.org>.
Arnaud Le Hors wrote:
> > public void addRecognizedFeature(String featureId);
> > public void addRecognizedProperty(String propertyId);
>
> Hmm. If that's what it is then I'd rather make them:
>
> public void addRecognizedFeatures(String[] featureIds);
> public void addRecognizedProperties(String[] propertyIds);
Fine. One call is better than many.
> One other problem with this config stuff (not your proposal) is that to
> allow an application to register its own components through the
> properties (to use instead of the default ones) I have to delay the
> creation of the pipeline until parse() gets called. As opposed to doing
Is it a reasonable scenario that the parser configuration
will actually change from parse to parse? I would prefer if
people were forced to create a new configured parser instance
if they want a different configuration for a new parse.
Or, in the case where the pipeline is reconfigured based
on application settings, then the behavior is undefined (as
well it should be).
--
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
setFeature/Property (was Re: cvs commit:
xml-xerces/java/src/org/apache/xerces/xni/parser XMLComponent.java
XMLParserConfiguration.java)
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Andy Clark wrote:
>
> Okay, thanks for the clarification. I just sort of freaked when
> all these changes were made without much reasoning behind it. I
> feel much better now. :)
The fact you don't know the reasoning behind a change doesn't
necessarily means there is none. :) I can see how much you trust me
now... ;)
> > SAXParser:
> >
> > check for SAX feature
> > if known process and send it to the config
> > else simply forward to the config
>
> Okay, so we have the situation where specific parser configs
> such as DOM or SAX add recognized features to the parser config
> but the parser is not a component. And if it were, then we have
> the recursion problem you mentioned.
That's a good summary.
> Simple solution. Add the following methods to the parser
> configuration:
>
> public void addRecognizedFeature(String featureId);
> public void addRecognizedProperty(String propertyId);
Hmm. If that's what it is then I'd rather make them:
public void addRecognizedFeatures(String[] featureIds);
public void addRecognizedProperties(String[] propertyIds);
> Then the parser can add the features and properties that it
> needs to recognize; everything is forwarded to and is managed
> by the configuration; and you avoid the recursion. Does this
> solve the problems we're facing? Or are there more?
Kinda. It does solve the problem but it's not optimal. It means that
even though the SAXParser already recognized the feature/property the
configuration is going to check on it. My check flag avoids this. But
I'll admit that this is probably not an area where performance really
matters.
One other problem with this config stuff (not your proposal) is that to
allow an application to register its own components through the
properties (to use instead of the default ones) I have to delay the
creation of the pipeline until parse() gets called. As opposed to doing
it at creation time. But this means the configuration object can't
forward to the components the features and properties that are set
before calling parse(). I don't have any components yet! Any ideas?
--
Arnaud Le Hors - IBM Cupertino, XML Strategy Group
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: cvs commit: xml-xerces/java/src/org/apache/xerces/xni/parser
XMLComponent.java XMLParserConfiguration.java
Posted by Andy Clark <an...@apache.org>.
Arnaud Le Hors wrote:
> I checked that in friday night before leaving the office and didn't have
> to time to explain. We have a problem that I'm not sure how to address.
> Let me get to it now.
Okay, thanks for the clarification. I just sort of freaked when
all these changes were made without much reasoning behind it. I
feel much better now. :)
> SAXParser:
>
> check for SAX feature
> if known process and send it to the config
> else simply forward to the config
Okay, so we have the situation where specific parser configs
such as DOM or SAX add recognized features to the parser config
but the parser is not a component. And if it were, then we have
the recursion problem you mentioned.
Simple solution. Add the following methods to the parser
configuration:
public void addRecognizedFeature(String featureId);
public void addRecognizedProperty(String propertyId);
Then the parser can add the features and properties that it
needs to recognize; everything is forwarded to and is managed
by the configuration; and you avoid the recursion. Does this
solve the problems we're facing? Or are there more?
--
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