Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

What is so great about JAXP

 
Greenhorn
Posts: 8
Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello all,
̈̈I have been working with SAX, XSLT, and DOM for a while. I played a little bit with Stax. What I can not get my head around is, why JAXP exists ?
I have read some articles, and they say it unifies the way we create the transformation and process it.
My understanding is, it makes connecting these processing API easy. So I can process a file in SAX, then feed the results to XSLT transformation, then if I want I can feed it into DOMResults, and process it using DOM.
This is great, but couldn't find one single example about this. When do I use SAXSource or StaxSource ?
May be I didn't understand something correctly.

And sorry if this is not the right forum to ask about this. Please advice.

Thank you.

 
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JAXP is simply the Java API for XML Processing - see for example, this wikipedia article.

In that article you will discover that JAXP includes DOM SAX StAX and XSLT APIs.

Harold's "Processing XML with Java" book is free online - a very complete reference.

Bill
 
Mansour Al Akeel
Greenhorn
Posts: 8
Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
William,
Thank you for helping. I understand it integrates them all. This is not worth calling it a new API. Anyone can package them in a jar.
Integration means getting all these APIs to work together, like I stated in my original post.
The question is, if that's what 's really meant by "integration", then how?
Let's say I have results obtained from SAX transformation (SAXResult), and I need to pass it through XSLT, then how do I go around this (if this is what JAXP for)?
If JAXP is not meant to do this, then it's just another package, aggregating popular XML processing technologies, and wouldn't call it an API !

I have read big portions of Harold's book, and the closest I was able to get http://www.cafeconleche.org/books/xmljava/chapters/ch09s09.html
If you can point me to a part that will get me closer to my answer, I will really appreciate it.

 
Marshal
Posts: 25682
69
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wrap your SAXResult around a ContentHandler. Then write an XMLFilter which uses that ContentHandler. Finally set up an XMLReader which uses that XMLFilter and have your transformation read from the XMLReader or its ContentHandler. Or something like that, the details might vary, but it should be covered in Chapter 8 of that book.
 
Mansour Al Akeel
Greenhorn
Posts: 8
Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator



 
William Brogden
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

This is not worth calling it a new API.



You are obviously ignorant of the history of programming Java for XML. Years ago when dinosaurs roamed the earth and XML got started, there was a tremendous profusion of XML parsing libraries. The Java wizards looked on this situation and saw it was bad, thus was created the JAXP API.

JAXP is designed to be an implementation-independent, portable API, meaning that any vendor's parser toolkit that meets the API specification can be plugged into a program that is written to the API. In practice, you will probably find the parser that comes with the Java Standard Edition to be satisfactory.



Quoting my 5 year old article.

Bill
 
Mansour Al Akeel
Greenhorn
Posts: 8
Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

You are obviously ignorant of the history of programming Java for XML.


Thank you for the complement

JAXP is designed to be an implementation-independent, portable API, meaning that any vendor's parser toolkit that meets the API specification can be plugged into a program that is written to the API. In practice, you will probably find the parser that comes with the Java Standard Edition to be satisfactory.



Ok, let me clarify this. In other words, the whole JAXP is about including parsers that are most frequently used, and that are able to solve most of the problems. Cool, this takes us back to point one, all that SUN did was to wrap them in a jar file or include them with their sdk. Seriously, they have created a factory to generate parsers for these technologies, but then the purpose for a factory is to make the calls to return any parser the same. Let me try to explain with an example, about SAX. Here's the old way to create a SAX Parser:



The great way of JAXP is:



Bill, there are extra steps involved in JAXP way. I don't see a use of this. The first way was implementation independent as well.
May be there's something I am missing here. can you please kindly elaborate ? Why would I want to create my sax parser the second way.


Quoting my 5 year old article.


Is there another place where I can read this article without registering "for free" ?

 
Mansour Al Akeel
Greenhorn
Posts: 8
Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bill,
To add more, what I expect in an integration API is to be really able to call any of the underlying technologies in the same manner, and this integration should allow me to use these different API as if they were processing a pipeline. So the results of SAX processing (events) can be feed into DOM processor, then I can take the results of the DOM processing and put it into StAX or XSLt processor.
I can do this without jaxp or "integration" API, but it will take me extra work.

I hope my point is clear now.
 
William Brogden
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No your point is not clear:

The whole point of JAXP is that you can substitute any implementation as long as you code to the interfaces specified ie "in the same manner."

In the history of using Java with XML, the creation of JAXP was (IMHO) a major success of the Java Community Process.

If you are interested in "pipeline" style processing, ServingXML is open source. There is actually quite a bit of activity in pipeline style processing - see for example my article on the topic. And no, thats the only place you can read it, that traffic is why they pay me to write articles.

Bill
 
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JAXP is "not" an integration API. It is a higher-level API that sits above the lower-level API, e.g. SAX, DOM.

Ideally, an XML-based data processing application can write to the JAXP API using one lower-level API and easily switch to another lower-level API with minimal code changes. This is not possible if the application is written directly with the lower-level API.

Again, JAXP is "not" an integration API. JAXP does not "include" SAX or DOM, it provides a bridge for client code to use SAX or DOM in an efficient manner.


Code ----- > JAXP ---------> SAX

Code ----- > JAXP ---------> DOM


The code above does not use SAX or DOM API directly. Using JAXP is a best practice when writing XML-based data processing applications.
 
Ranch Hand
Posts: 1491
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So the results of SAX processing (events) can be feed into DOM processor, then I can take the results of the DOM processing and put it into StAX or XSLt processor.
I can do this without jaxp or "integration" API, but it will take me extra work.

Any one confirm this ?
 
Mansour Al Akeel
Greenhorn
Posts: 8
Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you all for the help. I understand now JAXP is not what I thought (or hoping) it's. I can not feed the results from a transformation into another type. I need to write my own or use an existing adapter.
Pipeline frameworks (ie, apache cocoon) exist for this. It would have been really great if something like this exist with SDK. If we have existing components, each of them performs some processing, I would be able to connect them together, and get what I need.

II will just use JAXP for the fact it's there. But honestly, I don't see the benefit. Let's not talk high or low level, I included a small example. And yes, I got the idea, instead of calling sax factory to create a parser, I ask "Jaxp Sax parser factory" to create the parser for me !! Big deal.

With regard to creating different xml representation from SAX to DOM, or Stax, is very possible. I don't see what is hard about it except the extra time spent.

http://www.ibm.com/developerworks/java/library/x-tipcdm.html
http://ws.apache.org/jaxme/apidocs/org/apache/ws/jaxme/util/DOMBuilder.html

Thank you all.
 
William Brogden
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You may find the work on XProc - XML Pipeline Processing to be helpful.

I don't know how far this open source project has gotten on implementing XProc.

Bill
 
Mansour Al Akeel
Greenhorn
Posts: 8
Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bill,
thank you for all the help. I had a look at Proc.org as well, and I may go down this route.
However, speaking about JAXP, I think I am getting closer to what I can do with it.
In fact, integration between different processing technologies if "VERY" possible. I missed this point, and took me a while to start seeing it.
To make things easier, ideas from java.io and streams can be borrowed to explain this. To me the use of JAXP is not only constructing parsers and hiding the details of calling them, but it's in the Interfaces Result and Source.
Thinking again in terms of java.io, we have InputStream and OutputStream, and they can be wrapped in any way to provide some sort of functionality for applications. This is similar to JAXP Result and Source.

Here's an example. Let's say I have a transformation that reads XSD schema doc, and parses it to generate the layout for a database. This transformation is done through SAX. However, since SAX reads events only in one direction, this transformation takes only XSDs that follow Salami Slice design.
Now I need to get it to accept any design, so I will convert any schema design (ie, Russian Doll) to Salami Slice, so it can be parsed properly. Since some XSDs can be huge, I will use Stax for this extra processing.
This can be done without JAXP by writing the results of the Stax Transformation to a file, then give the file to my SAX transformation. Or like I stated earlier, convert Stax Events to Sax events. Either one would work.
With JAXP, I can just wrap the Source for SAX in another Source object that will do the "pre-processing". Of course I have to implement the Source interface, which is basically writing the results of Pre-processing to a file !

Definitely this can be in may ways, but doing it through JAXP makes me able to swap the implementation of the MySourceImpl with another, without changing the code a lot.
If I am not wrong on this, and if that's what other participants meant, then yes, JAXP allows me to use ALL these processing technologies together, simply by passing Source and Result around as files.

Thank you.
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

...it provides a bridge for client code to use SAX or DOM in an efficient manner.

 
Dinner will be steamed monkey heads with a side of tiny ads.
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
    Bookmark Topic Watch Topic
  • New Topic