Something just occurred to me. How does JAXP cope with all of these possible subsets? Actually, it would seem that Crimson vs. Xerces may have already run into the problem, but let me back up...
We have all of these XML processors with different capabilities that are "JAXP-enabled", or one can readily imagine they could be, and we are building more and more complicated "applications" that are using a greater number of "middleware" services that use XML and are JAXP clients. It seems harder and harder to believe that one can "know" which XML processor they are going to get from the JAXP factories and yet it seems more important than ever that every service in the application processing model gets a processor that meets its need. So, while Xerces can provide DTD-only parsers, non-validating parsers, parsers without DTD code at all (think SOAP), etc., if the clients of these parsers get them via JAXP then every software component in the address space will get them as well. 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 that if someone gets Crimson instead of Xerces via JAXP that all of the Schema dependent clients are out in the cold. It seems that it will be harder over time to assert that you will not need the union of all possible features available via JAXP given the increase in dynamic applications today (think plug-ins). Does anyone else see this issue popping up? -Glenn --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
