[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Article on JAXP 1.3 "Fast and Easy XML Processing"
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)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|