Design Choice (XSLT, other)?

[eight968]

Part 1:I have an XmlBean that I'm trying to convert into a RSSFeed. I see two ways to do this: 1) Use a library like Java's ROME and manually pull data from my XmlBean and put it into a SyndFeed. 2) Create a XSLT that converts my document into an RSSFeed. Which of these methods is "cleaner"/"better"/"righter"? Part 2:Method 2) seems a cleaner solution to me, but I still need to do this conversion on the server. Can anyone point me in the direction of some Java libraries that make this possible (a link to an example applying a stylesheet to an xml document, preferably with the document is represented as a xmlbean or a string, would be most helpful).Part 3:Is there a better option that I'm unfamiliar with than 1) or 2)? Thanks,Charles

[boen_robot]

I haven't heared of or used XMLBeans, so I'm sorry to say I don't exactly know what you're up against, but I don't think I need to.You're right. XSLT is truly cleaner, and it's also future proof. What if you decided you want to generate the RSS feed from another source? Or if you'd like to reuse the RSS feed in another language?Probably the best XSLT processor nowadays, Saxon, has a JAVA API. Documentation is included on the site. While it's an XSLT 2.0 processor, it can also process XSLT 1.0 stylesheets.

[eight968]

XmlBeans is basically the third method of parsing XML (SAX, DOM, XmlBeans). You basically have an XML file in (myfile.xml)XmlBeans mybean = XmlBeans.parse("myfile.xml")Now you can interact with the xml as if it were a java object. So if we had something like:<Base><Age /><Location /><Person><Organization @name="name" /></Person></Base>To get the Organization, we would:myBean.getPerson().getOrganization(); You can also run XPath and XQuery against it using SAXON (but annoyingly, my development environment is defaulting to XPath1, so I can't run a query like //Organization[@name = 'name']. However //Organization works fine. I was hoping someone would say option 1) was cleaner, so I don't have to figure out which setting is causing the problem.

[boen_robot]

XmlBeans is basically the third method of parsing XML (SAX, DOM, XmlBeans). You basically have an XML file in (myfile.xml)XmlBeans mybean = XmlBeans.parse("myfile.xml")Now you can interact with the xml as if it were a java object. So if we had something like:<Base><Age /><Location /><Person><Organization name="name" /></Person></Base>To get the Organization, we would:myBean.getPerson().getOrganization(); You can also run XPath and XQuery against it using SAXON (but annoyingly, my development environment is defaulting to XPath1, so I can't run a query like //Organization[@name = 'name']. However //Organization works fine. I was hoping someone would say option 1) was cleaner, so I don't have to figure out which setting is causing the problem.

Actually, your first expression is a perfecly valid XPath 1.0 expression also. Bug in this processor version?Anyhow. I say XSLT is cleaner mostly because I'm personally having hard time reading anything non markup. It misses the tree structure which gives the "this depends on that" feeling.Even if that's not the case with you, migration is another thing to consider. XSLT processor you can find for any language and will always produce the same output. Rewriting the call to it is usually very easy. Things of course complicate a bit if you need to pass parameters on conditions, but even then, it's easily doable. XMLBeans you can't find outside JAVA. DOM you can find, but scince the way different DOM implementations require you to use DOM, you'd still need to rewrite the whole thing. Fortunatly, scince DOM too is a standart, rewriting is easier, as you only have to replace the syntax constructs. For example, replace "." between objects with "->" if you were to migrate to PHP.Btw, there is a W3C draft now, XProc, which is even going to ease migration between one set of XML components (XSLT processor, Schema validator, etc.) to another. You'd only have to call (or simply turn on by default as with an Apache module) an XProc processor, which is going to take care for the rest. This includes, but is not limited to, selecting between various Schemas and XSLTs, passing parameters to the XSLT stylesheet on different conditions, perform XIncludes on each step along the way (if needed), making minor modifications to the XML, executing custom applications for handling XML files, saving or displaying the result, etc. With it, the only thing you'll practically need from JSP or any other S3L would be to perform negotiations with the client and pass the results to the XProc processor. Optionally, you might also want to perform custom actions and pass their results to the XProc processor as well.I didn't get it though... can you possibly install Saxon or ask the host to do so? If so, just do it. I guarantee you won't regret it. If not, well... what XSLT processor do you have? As far as I know, JSP doesn't ship with one.

[eight968]

I've decided to go with the XSLT approach. It seems cleaner to me, and cuts down some of the code that doesn't provide any business logic. XMLBeans uses Saxon to perform queries, but the problem I was having with executing XPaths earlier turned out to be from using an older version of XMLBeans that didn't provide full support. For some reason, an old version was packaged with BEA's WebLogic Platform 9.2 (which I am tied to, which in turn ties me to Java). I must say XMLBeans provides the nicest approach of XML manipulations in code than anything I've used before. It's certainly worth looking into if you're not worried about language portability.I was looking into XProc per your suggestion. It seems to have great promise. But I have two concerns. It seems like one use of XProc will be to support legacy schemas (handle version 1 of my schema this way, but treat version 2 this way). From a cost standpoint, many companies might choose this, but in the long run, it seems like the result will be multiple standards of encoding the same data and having code process the information differently. If we consider a military example, what communication aspects will occur if the Navy uses version 1, but the Army uses version 2 -- communication will be made more difficult. It just seems that several years down the road, the advent of XProc will yield a less standard-oriented approach. And my second concern is kind of related to this; developers will begin making poor design choices to accommodate XProc.

[boen_robot]

I've decided to go with the XSLT approach. It seems cleaner to me, and cuts down some of the code that doesn't provide any business logic.

I'm glad to read it. Don't hesitate to ask about anything with it .

XMLBeans uses Saxon to perform queries, but the problem I was having with executing XPaths earlier turned out to be from using an older version of XMLBeans that didn't provide full support. For some reason, an old version was packaged with BEA's WebLogic Platform 9.2 (which I am tied to, which in turn ties me to Java). I must say XMLBeans provides the nicest approach of XML manipulations in code than anything I've used before. It's certainly worth looking into if you're not worried about language portability.

I knew it. Old 'n' buggy (ok, ok... 'incomplete') implementation of XPath. As for XMLBeans... well, I do worry about portability, so XMLBeans is not the solution for me. Query() object all the way .

I was looking into XProc per your suggestion. It seems to have great promise. But I have two concerns. It seems like one use of XProc will be to support legacy schemas (handle version 1 of my schema this way, but treat version 2 this way). From a cost standpoint, many companies might choose this, but in the long run, it seems like the result will be multiple standards of encoding the same data and having code process the information differently. If we consider a military example, what communication aspects will occur if the Navy uses version 1, but the Army uses version 2 -- communication will be made more difficult. It just seems that several years down the road, the advent of XProc will yield a less standard-oriented approach. And my second concern is kind of related to this; developers will begin making poor design choices to accommodate XProc.

For the first problem I would suggest a pipeline that would validate the input against version 1 and apply an XSLT transformation to make it version 2. Version 2 would then keep on in the pipeline doing whatever else it's supposed to do. The new version could as well be saved somewhere or be offered to the Navy for them to save it.For the second concern... example? I'm betting I can figure a better approach for whatever you can throw at me (or if I can't... I'll offer a new component to XProc to the XProc WG for consideration that would do it). An ace I could always use is execution of a custom application. Something which XProc doesn't currently cover, but hopefully, it will. I mean, it is in it's requirements after all.All in all, any language could be practiced badly. There are bad HTML practices, bad PHP practices, bad XSLT practices, and I'm betting there are also bad JAVA practices even. But you just can't stop people from coding badly. The only thing you can do about it is to suggest and be a good coder yourself.