[
Lists Home |
Date Index |
Thread Index
]
- From: David Brownell <david-b@pacbell.net>
- To: Miles Sabin <msabin@cromwellmedia.co.uk>
- Date: Fri, 18 Feb 2000 15:31:50 -0800
Miles Sabin wrote:
>
> David Brownell wrote,
> > Jim Layer wrote:
> > > 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?
>
> I think we already _do_ have some experience with this sort
> of thing ... tho' not necessarily in the context of SAX. My
> factory proposal isn't particularly novel: it uses a service
> provider model that very similar to Sun's JNDI. The comparison
> is appropriate, because directory services are another domain
> where vendor neutrality and plug'n'play matter.
Configuration databases are easier to deal with than the
problems of what really needs configuring.
What I don't think we really have experience with is what
the options for these lower layers should be ... vs. which
should be in layers _above_ them. How many standard-ish
tasks really are there, after all?
On today's SAX2 features list, there are (I just counted) six
different features. Just how much help do people need to set
up six features, many of which often have fixed values?
> Anyhow, I'm all for letting a hundred flowers bloom. My
> proposals are on the table for anyone who's interested in
> evaluating them (http://www3.mistral.co.uk/miles/). I'd be more
> than willing to do the same for any concrete counter-proposals,
> including the 'do nothing' option ... so long as some sort of
> rationale is given.
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.
- 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
***************************************************************************
|
