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




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

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