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/27 22:30:12 UTC
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?
--
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