[
Lists Home |
Date Index |
Thread Index
]
Chris Burdess wrote:
> 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,
I explained the benefits. Do you see any problem if XPath APIs can work
with different 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?
This is not true. Transformation APIs and Validation APIs can support
other object model. I have explained in the mail below how JDOM can work
with Transformation and Validation APIs. Note that JAXP at the API level
doesn't add dependency to any other object model than DOM.
>
>> 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:
You are welcome to contribute to add the support of other object models.
As of now Sun JAXP implementation only provides the support of DOM.
JAXP XPath APIs doesn't prohibit any vendor adding support of other data
model in their JAXP implementation. As Michael Kay said that Saxon does
provide an implementation of JAXP 1.3 XPath API which supports object
models other than DOM.
> if the XPath interface can support arbitrary object models, what about
> the parsers and validation and transformers? What makes XPath
> implementations so special ?
Validation APIs accept Source as input and the same is true for
Transformer. So it is possible to provide support for other object model
for ex. JDOM.
As a matter of fact, JDOM does have org.jdom.transform.JDOMSource which
can be passed as input to Transformation APIs. Checkout the javadoc of
these class and you will get your answer. Same way support can be added
for Validation APIs. JDOM community might think of doing that. A JDOM
document can still be validated using
javax.xml.validation.ValidationHandler. This is explained
https://jaxp.dev.java.net/article/jaxp-1_3-article.html#Validating%20a%20JDOM%20document
>> 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.
A problem which can eat out most of CPU cycles for a very large time
such that system is not able to provide service becomes a security
consideration. Entity expansion is such a problem and as far as i know
this problem affects all the parsers. Though schema related problem is
not that serious compared to entity expansion problem.
>> 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
That is very dramatic - i would repeat what i said in my original
posting that an application can prevent itself against *known* security
attacks related to processing of XML .
Neeraj
|
