[
Lists Home |
Date Index |
Thread Index
]
- From: Jim Layer <JBLayer@netscape.net>
- To: xml-dev@xml.org
- Date: 9 Feb 00 16:32:57 EST
David Brownell wrote:
> 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?
A fair enough question. Miles' stuff solved an issue in the
environments and contexts in which I must develop in a more general
fashion than my current approach. I was/am enamored of a (potential)
standard way to more thoroughly abstract the creation process.
Agreed, there may be other, better ways to do this. Also, just
'cause this rings my OOD bell doesn't mean the rest of the world
should be saddled with the attendant baggage. I was not XML-aware
when SAX evolved so I don't know whether it was driven by the
insight the initial parser implementers or the experience of
those who used them (perhaps one in the same? ;-). Certainly,
this is more of a frosting on the SAX2 brownie and maybe everyone
would prefer to add their own flavor (or have it plain) <grin/>.
> > 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?
Nothing - and I would expect that's faster after the initial run,
though without the interface/provider portion of Miles' proposal,
each app, or the common logic on which they rely needs to maintain
some sort of list of SAX/SAX2 provider possibilities, as well as
recovery logic to do it again if the parser on which they rely
is swapped for another.
The provider file portion of Miles' proposal seems to provide
reasonable facilities to support more thorough encapsulation (for
the creation process) in that supporting logic need not be aware
of specifics like com.ibm.xml.parsers.SAXParser,
com.sun.xml.parser.ValidatingParser, org.apache.xerces.SAXParser,
and so forth. Instead, that logic only need know that a list of
these points can be found in one or more occurrances of
org/xml/sax/helpers/XMLReaderImplementation.provider files. The
interface portion supporting low overhead feature query brings
the *potential* for on-the-fly selection not always time practical
where "bigger" parsers (like those above) are in play.
The interface/query *is* more of a frosting, and in practice I
would expect many of our apps or supporting s/w might take the
query once and config approach to shave the 100ms in subsequent
runs. I do feel that the XMLReaderImplementation.provider concept
(or something like it) is a bit more fundamental.
> 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?
Guess I was unclear, and also using *apps* loosely - on our
systems other components that consume XML is more to the point. I
should also add that we're operating in a somewhat closed
environment, for a certain class of turnkey systems we provide,
though some (client) componetry is intended to also play in more
generalized environments.
I wouldn't expect *adding* to force use. I would expect to be
able to replace one parser with another of equivalent
functionality and interface with another with no change to the
components that rely on the interface and features. I certainly
can also accomplish that in our environment without benefit of
any of Miles' stuff, though I would make use of it in at least
some form if it was a commonly supported interface.
> > 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.)
Not *breaks*, just that a *custom* solution abstracting parser
creation on our systems doesn't necessarily extend well to more
general third-party software. Yes, that s/w can bring along it's
own parser and/or be configured during installation or whatever
to use what we have. It's a bit more footprint and another
(configuration) item to which somebody has to pay attention.
As to the servlet reference - Miles's touched on that on the
intro page to his extension proposal. I simply presumed he had
trod in mud my feet have yet to touch.
> 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.
No - not the wintel free-for-all (don't get me started on that ;-).
Simply that Miles' stuff (or something similar) would allow
apps/components/whatever to be designed to be adaptive to new
implementations that exposed a SAX2 interface without express
knowledge (on way or the other) of the entry point.
Regards,
Jim Layer
____________________________________________________________________
Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com.
|
