xml-dev - Re: ANN: SAX 2.0 extension proposals.

[David Brownell <david-b@pacbell.net>]

Miles Sabin wrote:
> 
> David Brownell wrote,
> > So, have a look at my pipeline package.  It layers code to
> > control some of those basic features, including validation.
> > You'll start to see why I don't think putting it into the
> > core of SAX is necessary.
> 
> Interesting, but, I think, orthogonal to the factory part of
> my proposals. As a means of constucting chains of SAX event
> processors it's quite nice (tho' I have a bit of a horror of
> String based specifications),

That's just a convenience for the simpler pipelines.  Makes it
very easy to them up and run them from the command line, without
writing classes.  When any stage needs serious configuration,
code still provides access to the full functionality.


>	 but it doesn't help to resolve the bootstrap issue.

It does help resolve some of the feature negotiation you were
worried about as part of bootstrapping.  Based on the processing
that needs to be done, some filters can be removed if the SAX2
parser driving the pipeline can achieve the same effect directly.

Which is part of why I pointed it out:  it DOES help resolve it.


>	 At some point or another you'll still have
> to programmatically reference some vendors parser.

Some chunk of code has to deal with configuration management,
and parser selection is only one of many such issues.  I'd really
rather that apps have internally consistent approaches, rather
than expecting each subsystem to use a different framework for it.

So IMHO it's actually good if the SAX2 core provides only minimal
hooks (e.g. what I sent before), and thus forces apps to deal with
their own configuration management issues in a consistent manner.

And no, I wouldn't be in favor of SAX2 endorsing a particular
scheme for configuration management.  It's an area where apps
need to vary widely -- from simple hardwired configs, to ones that
are centrally managed via hierarchical configuration databases
that are securely administered and which host automated integrity
checking.  It'd be as wrong to mandate one approach as another.


>	That means
> either hard-wiring a reference to that parser into mainline
> code, or coming up with an ad hoc factory solution.
> 
> Better to put that in the SAX core, I'd say.

I think we agree that some factory solution needs to be in the
core, but I'm advocating a simpler approach than you are.

What you're talking about is more of what I'd call a "broker":
provide a feature list, it assembles something suitable.  Such
modules often get discussed, but seldom implemented at lower
levels.  Lots of E-Biznesses are getting set up to provide high
level brokerage services -- best price on a commodity with some
feature (these chemicals, quality X, delivered to me by Wednesday,
billed to account) -- but brokers tend to need LOTS of options
to chose from before they get viable, in code or economic senses.

Part of the issue is that there really aren't that many parsers
that are worth even considering, so the need for a broker isn't
particularly strong (as I see it).

Another part is that in my preferred model of the future, parsers
are very similar in functionality, and the variability creeps in
through higher levels -- so again, there's little need for brokerage
facilities at the lowest level.

- Dave

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/threads.html
***************************************************************************