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 ]

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 

> 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


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

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