[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: ANN: SAX 2.0 extension proposals.

• From: David Brownell <david-b@p...>
• To: Jim Layer <JBLayer@n...>
• Date: Tue, 08 Feb 2000 19:34:39 -0800

Jim Layer wrote:
> 
> David Brownell writes:
> 
> > Miles Sabin wrote:
> >
> > > * A means of querying an XMLReader implementations features
> > >   without first having to instantiate an XMLReader.
> >
> > I'm not sure I see a need for that.  So far there aren't so
> > many implementations (those in my package, how many others?)
> 
> I'd suggest that Miles' proposal for this interface is more of
> a forward thinking approach along the vendor neutral line
> that resulted in SAX in the first place.

What's wrong with waiting till there's some experience with the
problem, and its solutions, before adopting a solution?  And maybe
trying out a few other solutions, as well as Miles', to see if a
standardized answer is needed?


> Without such a (lightweight) interface, there is no (standard)
> means of determining parser feature support without creating an
> instance of the parser.

And what's wrong with doing that once, and remembering the result?
Or even with saving it in a config file?


> > and I think manual configuration of system or subsystem
> > defaults is likely to remain appropriate for a while.
> 
> Manual configuration starts to get ugly as the number of apps
> and platforms on which they reside multiply. If each app maintains
> a configuration file, all must be identified and changed when/if
> the parser used is changed.

You seem to have some strange model of system operation that I can't
quite make sense of.  Why should adding a parser automatically make
any application use it?  Why shouldn't telling an app to use a given
parser include, well, saying how to use it?


>	 Even if all locally developed apps
> are designed to use a locally developed custom factory that
> isolates them from this issue (custom factory config must *still*
> be updated for parser change), this solution breaks down when
> third-party software that depends on a parser is introduced.

And exactly how would it be breaking?  If I add a web app to my
XML Servlet based environment, each app can add its own JAR files.
There's no need to replace a server default parser, or system default
one either.  (I notice you later used servlet environments as a
motivation for this feature ... I really can't see why.)

Seems like you're assuming something odd, like an installation model
that forces each app install to routinely break other apps that are
currently configured.  (Like on Win32.)  There are safer options.

- Dave

• References:
  • Re: ANN: SAX 2.0 extension proposals.
    • From: Jim Layer <JBLayer@n...>

• Prev by Date: Re: The Power of Groves
• Next by Date: Re: The Power of Groves
• Previous by thread: Re: ANN: SAX 2.0 extension proposals.
• Next by thread: RE: ANN: SAX 2.0 extension proposals.
• Index(es):
  • Date
  • Thread