[
Lists Home |
Date Index |
Thread Index
]
- From: Jim Layer <JBLayer@netscape.net>
- To: David Megginson <david@megginson.com>
- Date: 18 Jan 00 12:34:18 EST
David Megginson <david@megginson.com> wrote:
[snip]
>
> Yes, but in retrospect I think it might be overkill -- this kind of
> thing belongs at a higher application layer, not in a low-level
> driver. I was never too happy with the SAX1 ParserFactory either.
Fair enough, and I can see that there are larger fish to fry at the moment.
Maybe it does belong at a higher level but the concept does seem to resonate
with the general SAX theme. Our attraction to SAX (for data exchange
facilities) is that it allows us to (hopefully) avoid a heck of a lot of code
change associated with moving specific parsers into or out of our environment
(and we don't have to blow the whole document into volatile before dealing
with the data, of course).
The missing piece, at least in our context, is a similar abstraction to the
"get-a-parser" process. My first hack was a crude static Parser
getSAXParser(String features[]) with a lot of ugly, hard-wired "if" innards,
but if the app requests "Validation" (and we have deployed a parser able to
validate), it (ultimately) gets (a reference to) a Parser that validates.
As it stands, this works for us only 'cause the group that handles this (and
other) interfaces also controls which parsers are deployed on our systems and
when. The interface can be enhanced and deployed in lockstep with the
parser(s) and the app developers use the interface (or at least they are
strongly encouraged to do so) to at least reduce the potential for
modification when/if (more likely when) we change/add/remove a parser.
Sounds like hog-heaven except now we have looming on the horizon the need to
deploy and integrate with a piece of third-party middleware of sorts that also
needs a parser. Mutually nuts for them to use our interface (a "standard"
only on our systems). Implementation of a similar mechanism on their part
still injects another (although still relatively manageable) configuration
coordination point. Maybe I'm missing something (spouse says I'm a
Pessimist…I prefer Realist :-) but I can see this getting more convoluted down
the pike as XML and the various parsers evolve (and we hit our Nth third party
package).
A public, standard mechanism (widely supported as is SAX) to acquire a parser
by feature, would appear to at least mitigate, if not eliminate, this bit of
inelegance. Not necessarily arguing that this belongs in SAX2 (the list of
what I don't get about XML seems to be growing way faster than what I do get,
despite lurking xml-dev and grinding slowly through the various specs…). Also
currently devoid of vision at the moment as to the details behind such an
animal (the approach we've taken so far would be a maintenance debacle in a
general public context). Perhaps an idea to resurrect some time in the future
(or in some other context)...
Regards,
Jim Layer
____________________________________________________________________
Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com.
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ or CD-ROM/ISBN 981-02-3594-1
Please note: New list subscriptions now closed in preparation for transfer to OASIS.
|
