OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Article on JAXP 1.3 "Fast and Easy XML Processing"

[ 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 

>> 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 .



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS