[
Lists Home |
Date Index |
Thread Index
]
Chris Burdess wrote:
> Neeraj Bajaj wrote:
>
>> Check out the new article *"Fast and Easy XML Processing" *[1]
>> which explains the new concepts introduced in JAXP 1.3 (JSR 206) !
>
>
> Interesting, despite the utter dearth of definite articles.
>
> You talk about the benefits of an "object model neutral" XPath API,
> yet provide no examples of how any object model other than W3C DOM
> might work.
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.
However, I agree with your feedback that it would have been nice to take
the example of any other popular object model. By default JAXP
implementation only provides the support for DOM.
> 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. 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. DOM has been supported by JAXP for a long time.
But as i said earlier APIs doesn't prohibit an application to use
different object model. One can easily plug in support of different
object models as XPathFactory.newInstance(String uri) goes through look
up mechanism. [1]
>
> I'm also of the opinion that the "security enhancements" are a crock.
> What you're essentially saying is give the user an option to
> prespecify an abort if the implementation detects a condition it can't
> scale to correctly.
> Or perhaps I'm missing something - does it also specify, for instance,
> that URLs must use HTTPS or some other cryptographically secure
> protocol, and abort if that's not the case? If so, that's not in the
> documentation.
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. It is also possible other way where any
website could hang the browser (or client machine) by sending malicious
XML document. JAXP provides a way so that any application involved in
XML processing can behave in a secured manner and avoid denial of
service conditions.
Neeraj
[1]
http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/xpath/XPathFactory.html#newInstance(java.lang.String)
|
