[
Lists Home |
Date Index |
Thread Index
]
Neeraj Bajaj wrote:
> I have mentioned that though the default model is W3C DOM, it can be
> changed by specifying the object model URI. XPathFactory javadoc [1]
> also explains how the specific object model can be used. When
> designing the APIs, care has been taken that APIs should work with any
> object model and it will be evident looking at the APIs. Different
> applications use different object model for a reason as each object
> model has its own benefits. Object model neutral XPath APIs allows
> application to use same set of XPath APIs to work with different
> object models. Wit h this there is another advantage that user need
> not understand different (object model specific) APIs to work with
> different object model.
What I mean is, why has care been taken to ensure that the XPath API
works with arbitrary object models, when all the other APIs such as the
parsers API or the transform API or the validation API are blissfully
DOM- (or SAX-)specific?
>> DOM already provides its own XPath API, and I'm guessing that by
>> promoting the JAXP version you believe it's a better solution. Could
>> you provide any reasons for us to use and/or implement both APIs?
>> What other object models might be supported, and if they're so
>> important, why does JAXP not have core support for them?
>
> I believe you mean JAXP implementaion here.
No, I mean API. JAXP ships with the W3C DOM Level 3 Core interfaces,
and provides helpers like DocumentBuilder to create instances. It
doesn't have an equivalent JDOMDocumentBuilder or XOMDocumentBuilder
interface (or abstract factory class, if you want to be picky).
Therefore it has core support for W3C DOM and not other object models.
Transformers and validators use particular subclasses of Source and
Result (DOM, SAX, or stream, there's no XOMResult or JDOMSource or even
a generic ObjectSource) - although it's possible to extend Source and
Result for any particular object model it would be specific to that
implementation since there's no lookup mechanism or URI association
that can tell you what classes to use or how to bind them. These are
classes in the javax.xml.* namespace, therefore I mean API and not
implementation.
> By default JAXP implementation provides the support for DOM object
> model. It is not possible to provide support for all the existing
> object models as part of implementation.
Why not: if the XPath interface can support arbitrary object models,
what about the parsers and validation and transformers? What makes
XPath implementations so special?
> DOM has been supported by JAXP for a long time.
Certainly. Arguably JAXP would have had zero uptake if it had not
supported DOM.
> I am talking about the security implications related to XML processing
> and in the scope of JAXP. There have been instances that well-formed
> XML document (small size) can be written in such a way that when
> parsed can consume high CPU cycles resulting in denial of service.
> This could be a problem for any website which accepts XML feed, where
> hacker could potentially send such malicious XML document to degrade
> the performance of the system and possible result in denial of service
> condition which i see as "security" concern.
I don't see this as a security concern. I see this as a performance
problem which may or may not be present in any particular
implementation. Calling it a security feature is a marketing ruse.
> JAXP provides a way so that any application involved in XML processing
> can behave in a secured manner and avoid denial of service conditions.
By pressing the magic button I can make sure my webserver never goes
down or gets compromised? Ha
--
Chris Burdess
|
