Glenn Marcy wrote:
> [...]
> and yet it seems more important than ever that every service in the
> application processing model gets a processor that meets its need.

Precisely.

My personal opinion has been to use the JAXP factories only when 
the application needs standard, run-of-the-mill XML processing
that only requires validation and/or namespaces with DOM or SAX.
However, once the application goes beyond this and needs specific
customizations, the JAXP model starts breaking down. And using
the setAttribute method is no guarantee that the underlying
parser will support that feature.

In my own applications, I prefer to provide my own wrapper classes. 
This allows me to abstract the parser as much as possible in the 
application code while still allowing me to completely control the 
configuration of the underlying parser. For example, when I want
to use both XML and HTML parsers in the same application, there's
no way for JAXP to provide this for me. I end up writing non-
standard code but I can live with that. :)

But following your train of thought...

> Since we already have major subsystems that might have different
> parsing requirements, e.g. Xalan and Axis, how likely will it be
> in the long run to even have many choices.  It is already the case
> [...]

Is it possible for any factory to be flexible (and extensible)
enough to allow what you're talking about? Perhaps if you asked
the factory for a parser that supports a list of features and it
would only return a parser that supported those features. Then
the application would know what it's getting. For example:

 Ex 1: XML scanning + namespaces + validation - XML Schema
 Ex 2: XML scanning + namespaces - validation + XInclude
 Ex 3: HTML scanning + namespaces - validation

But I have doubts that this kind of a solution is even feasible.
Or at the very least, it seems very fragile. And what if the 
parser can't provide the parser features required? Is the app
dead in the water? Seems to me you're back to requiring specific 
parser implementations.

-- 
Andy Clark * [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to