Other voices: Intellectual Cramps

Intellectual Cramps is a weblog that discusses a lot of technologies related to this weblog. It is written by David Carver and contains a lot of posts about XML and Eclipse. Certainly one to add to your Google Reader!

Other voices: Versioned namespaces?

This week, there was a short but interesting discussion on the Cocoon mailing list regarding the namespaces to be used voor Cocoon 3.0. The question was: should namespaces contain a version number?

In short, the outcome is:

Don't use versioned namespaces; use versioned XSDs instead!

The longer version is in the archives: this is one of the key posts...

XRX and XPath 2.0

Here is the truth about XPath in the XRX architecture if you follow the specs literally:

Within the XForms spec, there is a small but important sentence though:

A future version of XForms is expected to use XPath 2.0, which includes support for XML Schema datatypes.

And that is just enough to allow XPath 2.0 usage within Orbeon Forms. It has been supporting XPath 2.0 for quite a long time already by the way.

Sneak preview: Cocoon 3.0 pre-alpha

Just out of curiosity, I checked out the current pre-alpha code for Cocoon 3.0 (aka Corona). To my surprise, it took little effort to build and deploy. Like Cocoon 2.2, it is based on Spring and uses Maven in the best possible way.

Cocoon 3.0 is a full rewrite of Cocoon by the people with experience from the earlier versions. It is designed to meet the demands of modern web applications. This means:

• Cocoon 3.0 aims to become the best platform for RESTful services
• You can use Pipelines without being tied to the Servlet API
• It is easier to integrate your own Java code into a pipeline
• Superfluous packages are cut out of the platform

It will be up to the client to provide stateful Form frameworks. This makes the platform an ideal replacement for a pure XQuery backend in an XRX architecture. For example, you can think of an Orbeon Forms - REST - Cocoon 3.0 combination... 

A more detailed post on the changes planned for Cocoon 3.0 is written by Reinhard Pötz, one of the driving forces behind the new Cocoon version.

Answering mail #9

Brian Reindel writes:

Hi Adriaan,

I just read "Create a maintainable extensible XML format" on IBM's Web site, and I had a quick question. How come the move from validating against a DTD to validating against a schema? I am using PHP and SimpleXML, which only provides DTD validation tools, while the new PHP DOM provides schema validation. I really want to use SimpleXML instead of DOM because it is much more concise. However, I need to do validation because my XML schema will be public and must be followed strictly. Can you tell me at what point it is absolutely necessary to move from using a DTD to using an XSD?

Thanks for any advice you can offer.

Brian Reindel

Hi Brian,

I think you can continue using DTDs for as long as you like. Document Type Definitions are mature, time proven, and still used to describe even the newest versions of XHTML. Many people are using it to describe their XML or SGML format and not just to maintain the old ones.

XML Schemas are popular because they are supported by many tools and recommended by the World Wide Web consortium. That does not stop a large group of developers from preferring DTDs or another alternative like RELAX NG - which shares some characteristics with DTD. Personally, I think RELAX NG (Compact Notation) is a bit easier to read than a DTD, but that may be different if you are used to reading and writing DTDs.

The main advantage of a DTD is that you can use inline notation within an XML document to describe its element structure. However, XML Schema and RELAX NG (XML Notation) can be expressed as XML documents themselves which make them easier to manipulate / translate. 

The main advantage of XML Schema is the possibility to put detailed restrictions on the content within an element. Using DTD or RELAX NG, you could put these restrictions in a separate Schematron validation with the added benefit that detailed element content validation and element grammar specification are not tightly coupled in one file.

If you consider my recent example translation to RELAX NG, you could also imagine doing the same translation to the DTD format below... (with my apologies for any errors: I do not know too much about DTDs)

The bottom line is: there is a lot of choice and it is fully up to you to decide. In this weblog, I'll try to cover more on RELAX NG and Schematron. For my own daily usage, I'd say "XML Schema, unless..." Your example is a legitimate unless, if you ask me! To stress this, here is a quote from Elliotte Rusty Harold's article "The Future of XML":

DOM isn't a least-common-denominator API: it's a worst-common-denominator API. You couldn't design a worse API for processing XML if you tried.

Kind regards,

Adriaan.

<?xml encoding="UTF-8"?>

<!ELEMENT car (brand,type,kind,(tr:tire|wnd:windscreen)+)>

<!ATTLIST car

  xmlns CDATA #FIXED 'http://car.org/car'>

<!ELEMENT brand (#PCDATA)>

<!ATTLIST brand

  xmlns CDATA #FIXED 'http://car.org/car'>

<!ELEMENT type (#PCDATA)>

<!ATTLIST type

  xmlns CDATA #FIXED 'http://car.org/car'>

<!ELEMENT kind (#PCDATA)>

<!ATTLIST kind

  xmlns CDATA #FIXED 'http://car.org/car'>

<!ELEMENT tr:tire (tr:brand,tr:type)>

<!ATTLIST tr:tire

  xmlns:tr CDATA #FIXED 'http://car.org/tire'

  tr:count CDATA #REQUIRED>

<!ELEMENT wnd:windscreen (wnd:brand)>

<!ATTLIST wnd:windscreen

  xmlns:wnd CDATA #FIXED 'http://car.org/windscreen'

  wnd:count CDATA #REQUIRED>

<!ELEMENT tr:brand (#PCDATA)>

<!ATTLIST tr:brand

  xmlns:tr CDATA #FIXED 'http://car.org/tire'>

<!ELEMENT tr:type (#PCDATA)>

<!ATTLIST tr:type

  xmlns:tr CDATA #FIXED 'http://car.org/tire'>

<!ELEMENT wnd:brand (#PCDATA)>

<!ATTLIST wnd:brand

  xmlns:wnd CDATA #FIXED 'http://car.org/windscreen'>

Other voices: REST

I tried to write something like this down myself before. But at least as interesting is to read it in someone else's words. How do you respond to this misconception?

Misconceptions About the REST Architectural Style

With that out of the way I can address the straw man argument presented in Damien's post. Damien states that building a RESTful Web Service is about using the HTTP PUT and DELETE methods instead of using HTTP POST when designing a Web API. In fact, he goes further to describe it as "the RESTful verb architecture" implying that choice of HTTP verbs that your service supports is the essence of REST.

This is incorrect.

In his post "Explaining REST to Damien Katz", Dare Obasanjo explains the advantages of REST in his words. A must read in my opinion!

People: Integration vs Standardization

What do you prefer: A complete software solution that works right out of the box and is capable of solving all your problems as long as you adjust it to a model prescribed by the product? Or do you rather spend several weeks or months setting up the optimal set of building blocks you carefully selected to meet the requirements?

Considering the questions from a distant viewing point, this seems like  a tough question. Many developers may pick a side with little hesitation though. And the argumentation of each side might be equally convincing.

The choice of programming languages may be a deciding factor. For example, .NET and Ruby on Rails specialists may argue in favor of fully integrated solutions: everything fits, it is meant for its purpose and it lives up to the promises in most cases. At least as long as you use the tool for the purpose it was meant for.

Experienced developers using Java or Python may be equally convincing with their explanation of the advantages of standardized components. Avoiding vendor lock-in, freedom to switch components and open data formats are some of their key points.

A standardization specialist can easily switch to an integration oriented platform. He is used to switch platforms and testing alternative components. In many cases, after making this switch, he will genuinely appreciate the ease of use for a while, and the feature richness and development speed that are typical for an integrated platform. Nevertheless he is unlikely to hesitate for a minute to give that up again in favor of independent components and standards and most importantly: freedom of choice!

The other way around might be a bit more difficult. Living in a relatively simple world of fully integrated platforms, there are many challenges in selecting your own set of standardized components that you might not know of. A common Ruby on Rails expert or .NET developer visiting the Java world is likely to spend a lot of time complaining about all the countless choices for modules and libraries. You might get a similar feeling when you try to select the best Linux distribution for your desktop computer. (Aaaaaarghl! ;-))

I hope it is clear this post only talks about differences in personal preferences. A discussion about the actual value of standardization or integration would be a bit longer. If standardization means that you are limited to using the greatest common denominator in features... And you are willing to pay the set up costs mentioned earlier... There must be some special value in standardization that is not mentioned in this article... Let's save that for later!

The more important question: is Integration vs Standardization the exact same thing as Application vs Infrastructure? Is there a significant correlation? Or are they completely separate of each other?

Answering mail #8

In a comment on the post "Introducing Orbeon XForms in 2008", Erik Bruchez wrote:

Adrian, good post, and overall very postive about Orbeon :-)

Just one precision: Orbeon does not use Dojo, but YUI. But if I may ask, why do you say Dojo is the worst possible choice?

-Erik (Orbeon developer)

Hi Erik,

Thanks for pointing out that mistake. It is Chiba that uses DOJO, not Orbeon. I put that sentence between DEL-tags. It is nice to know that Orbeon developers are reading this blog by the way!

I must admit that it is not a nice thing to say that DOJO is the worst possible choice. That is an opinion and depends on selection criteria. Your mileage may vary.

For me, there are two reasons why I am not fond of DOJO.

1. Its size: The full DOJO toolkit is 4.1MB compressed, 19.2MB uncompressed - compared to 16KB compressed for jQuery and 97KB uncompressed! Even though you might not use the full DOJO tool set and even though they do offer a 23KB compressed core, the usage of large libraries is not my taste.

2. IFrames. Where XHR is unavailable, DOJO tries to fall back on IFrames. It is worth a separate post to point out the disadvantages of IFrames. The main point here is the possible security vulnerabilities.

Personally I prefer JQuery. Here is a set of slides that introduces jQuery and how it follows the principle of Progressive Enhancement rather than Graceful Degradation:

http://www.slideshare.net/simon/unobtrusive-javascript-with-jquery

It also mentions YUI and DOJO on slide 47. 

Thanks again!

Adriaan.

Other voices: 97 Things

My colleague, Bart Kooijman, wrote an internal e-mail with the subject "97 Things Every Software Architect Should Know":

Hi all, 

  

When we talk about skills in software development we tend to think about the hard skills first. Java, JEE, Maven, UML, PHP, HTML, Object Oriented Design and so on. We think about them first because we think they are important. And, yes, to some extend they are. But there is more to it.

Once you start working with all these hard skills and apply them in your projects you learn the concepts behind them. And once you see the concepts you will see the concepts behind the concepts which are the general principles/guidelines in software development every developer and software architect should know and work with.

  

Richard Monson-Haefel has done an excellent job in writing down some of the most important concepts, principles and guidelines together with the community. It is something I have been looking for a long time. A great effort from him. Check it out on http://97-things.near-time.net/wiki.

One of the best ones I like from the site is this one http://97-things.near-time.net/wiki/show/challenge-assumptions-especially-your-own. I make this mistake still to often.

Enjoy it and hopefully learn from it(and challenge it if you will :-),

Bart.

Dividing the Java spectrum even further

In two previous posts ("Reevaluating XML in the Java spectrum" and "People: Infrastructure vs Application"), I gave my opinion on how the Java community can be divided over roughly three clusters. Despite the common choice for Java, there is a noticeable difference in the tool selection in each cluster. In my opinion, this is a result of different preferences.

(Again, please note that my opinion is NOT based on official research and is NOT supported by the vendors mentioned in the picture!)

To explain the opinionated tool selection in this Weblog, I'd like to further elaborate my view on the clustered Java universe. I think each cluster has its own modeling approach, audience and future direction. Here is my opinion on these additional dimensions on top of the original picture:

Original spectrum:

Modeling approaches:

Audience:

Future direction:

What do you think? What are the additional dimensions you can think of? Send your feedback to adriaandejonge@gmail.com 

Answering mail #7

In reply to the post "People: Infrastructure vs Application" I exchanged some comments with Mark Berck; here is a summary - read the full conversation under the original post.

You can visit Mark Berck's blog in Dutch at http://markberck.nl/  

mark berck said...

[...]

Reading your post I get the feeling that you really think that Infrastructure can't be mixed with Application, while I feel that there are situation where you don't want to separate these concerns.
[...]

adriaan de jonge said...
[...]
What are the situations where you feel you don't want to separate concerns? I am curious whether I can address these. If not, I would be happy to acknowledge I am wrong on this one!
[...]


mark berck said...
My opinion is, that for small businesses, stand allone applications, this is the perfect way to go.

But if your application is part of something bigger, the application uses shared data sources, publishes to other system, etc. I completly agree with your statements.

Mark

I see your point. I think it is wise to make a clean separation between

1. what is possible now
2. what is desirable later

Thinking about current possibilities, it is not always easy or possible to make a clean separation between Infrastructure and Application level. This is especially the case within smaller environments. The popularity of products like Joomla, Liferay and Access (your own example) are signs that moving away from technicalities maybe even more desirable in smaller environments than in large enterprises.

Products like Intalio may be too much for such environments. I am still curious whether a proper PHP / Visual Basic programmer could get effective results out of a product like Orbeon following the XRX pattern. I think such a product would be a nice first step also in smaller environments.

Introducing RELAX NG

Previous posts mentioned RELAX NG as an alternative to XML Schema. There are both advantages and disadvantages to using that technology. Before mentioning all these, it might be interesting to see what your first impression is, just by giving an example.

This example is a translation from the XML Schema presented in the developerWorks post on creating maintainable and extensible XML formats. It is from the section "Design a more general format". This is RELAX NG Compact Notation:

default namespace = "http://car.org/car"

namespace tr = "http://car.org/tire"

namespace wnd = "http://car.org/windscreen"

start =

  element car {

    element brand { text },

    element type { text },

    element kind { text },

    (element tr:tire {

       attribute tr:count { xsd:integer },

       element tr:brand { text },

       element tr:type { text }

     }

     | element wnd:windscreen {

         attribute wnd:count { xsd:integer },

         element wnd:brand { text }

       })+

  }

People: Infrastructure vs Application

If your development team is larger than 5 developers, it is likely that you have at least one developer with high quality standards. As your team size increases, there's a good chance, you have yet another, maybe even more demanding developer.

Considering you have two developers demanding high quality code, there is a good chance they have a very different opinion about what makes good code. Somehow, this does not necessarily cause conflicts however. In many cases, both colleagues appreciate each others demanding attitude and they are willing to learn from each other.

The question is whether they actually copy each other's habits though...

There are roughly two ways you can handle your code: you can consider code as a list of instructions intended to make the computer do what you want it to do. Or you can use code as modeling tools to describe the real world and make it come alive. The resulting computer program is considered an implicit result of the working model.

Instructing the computer is done on Infrastructure level. Building models on Application level requires a working infrastructure . In an ideal situation, your infrastructure logic and your application logic fit together well but are clearly separated.

If you have developers with different quality standard, the chances are that one is more interested in infrastructure level and the other is more interested in application level. This could be a perfect team.

More problematic is the tendency to mix infrastructure and application, not being aware of the potential problems of this approach. In my drawing a few posts ago, this tendency can be seen in developers with a preference for the Sun cluster:

Technology in the IBM cluster offers more options to make a clear separation between infrastructure and application. More about such technologies in upcoming posts.

Wish list: Two way XSLT

You already knew that you can use an XSLT transformation to convert data from one XML format into another XML format. Something like this:

Last week I remembered that a few years ago, just before I discovered XForms, I was actually looking for an XSLT processor that works bidirectional. Meaning that after the transformation, if you change something in the output document, the equivalent values in the input document also change. Like this:

Back then, there was an alpha quality example project called Wobzilla that demonstrated a technique that works this way. XForms also works this way, but that is a bit less flexible than two way XSLT. The latter can be used in a pipeline and might even function under an XForm to simplify the input/output document used in the XForm.

How difficult is it to create technology like this that works in a Cocoon pipeline or an Orbeon pipeline?

This is a post from 2003 explaining the Wobzilla demonstrator.

Other voices: "Anything you can do, I can do meta"

In January 2007, Technology Review published an interview with Charles Simonyi, the original creator of Microsoft Office and Hungarian notation. In this interview, Simonyi outlines a different way of thinking about software development that might become fundamental for the way we treat software in the next decade.

Simonyi shares much of the common dissatisfaction with software. "Software as we know it is the bottleneck on the digital horn of plenty," he says. "It takes up tremendous resources in talent and time. It's disappointing and hard to change. It blocks innovation in many organizations."

Simonyi's ambition is to unstop that software bottleneck--characteristically, by going meta. He's developed an approach he calls intentional programming (or, more recently, intentional software), which he hopes will overturn programming. If Simonyi has his way, programmers will stop trying to manage their clients' needs. Instead, for every problem they're asked to tackle--whether inventory tracking or missile guidance--they will create generic tools that the computer users themselves can modify to guide the software's future evolution.

There are many ways you can fill in this philosophy. In my opinion, pure XML platforms on top of Java foundations may become key technology to this way of thinking. Take a look at Intalio for example (which uses Orbeon XForms by the way).

Read the full article over here. Yes, it is long but it is worth reading!

XML is NOT about tree structures

On first sight, XML appears to be all about trees. And on second sight, reality seems to confirm this misconception:

• The internal structure of XML parsers is based on trees
  
• Most custom XML formats follow rigid tree structures
  
• XML critics introduce alternative notations to describe trees
  
• Poor usage of XPath is restricted to basic tree traversal
  

Of course you can use XML to model trees. The title of this post does not intend to question those capabilities. XML is very well capable of capturing structured data.

The point is that most XML does not live up to its full potential. The real potential of XML is in semi-structured data. Modeling only structured data with XML means being stuck in second gear.

What is semi-structured data?

The difference between semi-structured data and structured data is in the degrees of freedom. You can mix your elements in countless variations of compositions. Instead of rearranging your data into a flawed tree format, you can choose an outline that fits the document being modeled.

This may sound abstract and theoretical or it may appear messy and unpredictable. But before you question semi-structured nature... Are you aware that you already know a semi-structured format that is a major standard available on almost any computer anywhere in the world? 

The XHTML standard is the best possible example of a semi-structured format. Although browsers parse it into a DOM tree under the hood, its real world representation is a document. When writing XHTML you can think about markup freely. You're not wasting energy thinking how to force your data in an inadequate tree.

To stress the importance of its semi-structured nature, imagine what XHTML would look like if it was designed according to the tree based philosophy like most formats:

<html>

<title>Tree structured XHTML</title>
<content>
<h1>
<title>First chapter</title>
<content>
<h2>
<title>Example section</title>
<content>
<span>Formatting would have been</span>
<span class="em">much</span>
<span>more work.</span>
</content>
</h2>
<h2>
[...]
</h2>
</content>
</h1>
<h1>
<title>Second chapter</title>
<content>
[...]
</content>
</h1>
</content>

</html>

Answering mail #6

An anonymous comment on the IBM developerWorks article "Create a maintainable extensible XML format" says:

The situation is simplified if one creates named types rather than adhering to the DTD convention of working with elements. The use of named types permits a one-to-one correspondence to JAVA and other object oriented languages, such as C# and Ada. 

That is valuable feedback. Although I do not fully agree, it does make a new point and it is food for further discussion...

Within the article, named types are used in the section "A word about extensions". This demonstrates the advantage of named types for extensibility.

"Simplifying the situation" is not the first thing I'd think of though when talking about named types. Their purpose in XML-Object mapping is new to me, but I can imagine they have their added value there. Personally I prefer using API's like XStream for that purpose, because it just serializes XML regardless of its schema.

XStream is what I used in the developerWorks article "RESTful SOA using XML".

An additional advantage of that approach is that it also allows you to serialize XML formats that are described by a RELAX NG schema instead of an XML Schema. RELAX NG is more DTD style, like most XML Schema examples in the article.

There is another advantage of using named types that is not in the article and not in the comment, but still within the scope of the article because of maintainability. This is the fact that a named type can be reused under multiple different element names. Think for example about a <VisitorAddress>, <PostalAddress> and <BillingAddress> all containing the same <Street>, <Number>, <PostalCode>, <City>, <State> and <Country> elements.

XML Schema can do a lot more than what was shown in the post, and things that are not possible in RELAX NG. An interesting discussion is whether such detailed constraints actually belong in a schema or not. But that is a whole different post! :-)

Differences between XML 1.0 and 1.1

There are days when you think you know XML. But every once in a while you meet someone who asks a very basic question that you cannot directly answer. Most of the time it is just a minor detail you can look up in the spec. Some details however, feel like very relevant details.

For example, a recent issue of the German magazine Java Spektrum discussed new XML technologies. Part of this is the difference between XML 1.0 and XML 1.1. And the question is: "is it important?"

This is a snippet from the Spec on W3C.org:

The overall philosophy of names has changed since XML 1.0. Whereas XML 1.0 provided a rigid definition of names, wherein everything that was not permitted was forbidden, XML 1.1 names are designed so that everything that is not forbidden (for a specific reason) is permitted. Since Unicode will continue to grow past version 4.0, further changes to XML can be avoided by allowing almost any character, including those not yet assigned, in names.

http://www.w3.org/TR/xml11/

This sounds fundamental. Basically it means that (generally speaking) a well-formed XML 1.0 document is also well-formed in XML 1.1. But XML 1.1 documents are not necessarily well-formed in XML 1.0.

The next question is: who is waiting for the changes in XML 1.1. Aren't many people still using XML 1.0 for most purposes?

I think this depends on the language of your format. If you are designing a format with English tags, XML 1.0 is all you need. For languages like Dutch and German, XML 1.0 is still a reasonable choice. For languages using many special characters, things may be different.

From an Agile XML perspective... Is it more agile to design a format with tags in your own language / characters than it is to translate everything to English?

developerWorks: Create a maintainable extensible XML format

IBM developerWorks just released the article I wrote together with Sally Slack on creating your own XML format.

This is the abstract:

Create a maintainable extensible XML format

Reduce change when you design XML formats agile enough to incorporate new requirements

XML is a communication format for exchanging structured documents and data. Too often, an XML format is chosen arbitrarily and on the fly during development, without much planning or design. Design the right XML format up front, and you can meet the needs of everyone involved in the communication. If you don't, you're in for a long journey of format revisions. Learn how to design a format less likely to require change and agile enough to incorporate new requirements with the simple addition of new extensions instead of full changes.

The main points explained in the post:

• Stop treating XML Schemas as generated technicalities
• Use multiple namespaces and mix them
• Mind the details
• Think the XML way
• Plan extensibility up front

I hope the article helps! Read more over here:

http://www.ibm.com/developerworks/library/x-extensxml.html

Other voices: XRX

The newest buzzword supposed to beat LAMP over the next few years is XRX:

XForms + ReST + XQuery

At least when it comes to XML technology, this combination should be up for the job. A nice feature is the scalability of the architecture: it is easily extended with additional layers, for example in SOA environments.

In May there was a post on XML.com called

XRX: Simple, Elegant, Disruptive

This post still uses the Mozilla XForms plugin as a client. As other posts point out, the Orbeon XForms platforms qualifies for the title XRX just as well.

Read more in this post!

Answering mail #5

Harvinder Singh wrote:

Hi Adriaan,

I have one doubt on Restful service. What is the defintion of Restful service?

When can I call my service a Restful service? Any web application which is not using SOAP seems to me as an Rest service.

Regards

Harvinder

Hello Harvinder,

Unfortunately that is what a lot of people think. Personally, I call most of such non-SOAP services by the name XML over HTTP.

Just a very few of those services are actually RESTful. Most important properties of these services are the fact that they are stateless (meaning no session ids or long living connections) and they use descriptive URLs to describe resources - which can be manipulated with just a very few simple actions.

They don't necessarily use XML, but that is the format of my preference.

I hope you can recognize the beauty of REST compared to XML over HTTP.

Kind regards,

Adriaan.

Answering mail #4

Jeff Lu wrote:

Hi Adriann, I've just finished reading the first three of your four tutorial series. I want to drop you a note of thank you for a thorough and practical tutorial you have put together. This is exactly what I'm looking for to do dynamic and data driven forms. Please keep writing and share your experience and insight on Xforms. Just an FYI, tutorial-part-2.xhtml & tutorial-part-3-repeat.xhtml links are broken. I really would like to the sample code for tutorial-part-3-repeat.xhtml. Also if you have an example of an xform that binds several xml source documents and each xml document has its own xsd, would you post it up or email me the example source code? Thank you again Jeff

Hi Jeff,

Thanks for the positive feedback and sorry the examples are no longer there. I am working on a new series of posts rewriting the old tutorials with new and updated examples that do justice to the year 2008.

This is a first start...

Kind regards,

Adriaan.

Answering mail #3

Tiago Giusti wrote:

Dear Adriaan,

My name is Tiago Giusti, I'm from Brazil, Santa Catarina Province, and a student of the highschool UNESC (www.unesc.net). I need to write a short article about SOA with XML or something else, wich will be it showed on a big event about technology here is this university in November, 2008.

I read your document: http://www.ibm.com/developerworks/library/x-restfulsoa/ and I got take something, but not everything.

Could you help me, sending to me some links, documents, texts, and more things that may help me to construct it?

I'm looking for, but how I found much documentation just in english, over myself 'cause my English, wich is so bad!!!

If you know about a documentaion a little simple about all it, with examples, images, I will be so thank you.

Take care,
Tiago Giusti

Hi Tiago,

Actually, that article was intended to be simple documentation. But the definition of "simple" may depend on your background knowledge. Some basic Java and XML knowledge is required.

The open internet may not be the best source for information. Sometimes the bookstore is a better and more friendly place for information. For example, I got a lot of interesting information recently from this book:

Web Service Contract Design and Versioning for SOA
By: Thomas Erl; Hugo Haas; Anish Karmarkar; Kevin Liu; David Orchard; Priscilla Walmsley; Umit Yalcinalp
Publisher: Prentice Hall
Pub Date: August 04, 2008
Pages: 550

This is available online on Safari.

Good luck with your technology event in November!

Adriaan.

Answering mail #2

Melody Liu wrote:

Hi, Adriaan:

I have read your paper "RESTful SOA using XML" from http://www.ibm.com/developerworks/xml/library/x-restfulsoa/
I want to do a experiment about the content in order to understand more, but the code given in this paper only include servlet, no jsp and xml.
So, could you please send me the whole code project? I really want to take. Thanks in advance!


Best regards,
Melody

Hi Melody,

Thank you for your response and my apologies for the late reply.

The code example is just a very minimalistic basic sketch of what a solution would look like when you are following the solution patterns described in the article. If you're saying this is not a realistic example, I fully agree with you. If I'm not mistaken, that is already acknowledged in the text itself.

However, if you are asking for JSPs or XMLs... that is a whole different point. In the solution the way it is set up in the article, there aren't any. Here, the Java objects are representatives of the XML elements and the XStream API is used to map them from and into XML on the fly when handling GET and POST requests.

This assumes most of your business logic is written in Java and you are connecting to services the way you develop them on a platform like Spring.

Recently I started thinking about working more with native XML platforms and use Java only for the underlying infrastructure; not the application itself. Solutions as described in the article may should become a lot simpler (almost trivial) using such software.

I am still working to write that down in a series of comprehensible blog posts. I hope you are already doing well with your experiments.

Kind regards,

Adriaan.

Introducing Orbeon XForms in 2008

My criticism of XForms written in 2006 is outdated. In my new series of posts, you can recognize my efforts to prove my old arguments wrong. Basically, there are three fundamental issues to be resolved:

1. Web browsers do not support XForms

2. There is no shrink-wrapped solution handling the server side of the equation

3. XForms are too complicated for the average developer

And this is the roadmap to address them:

1. The server side implementations of XForms are now mature enough to eliminate the need for XForms support in the browser. Although XForms plugins may be applied in closed environments, the open internet can be served with the current AJAX-based technology.

2. At least one of the server side implementations - Orbeon - has evolved into a full stack framework. In addition to XForms, it offers a native XML Pipeline mechanism to handle requests and integrates Exist Native XML Database (NXD) as storage back end right out of the box.

3. To get an average developer up and running with XForms, requires a complete and thorough explanation of key XML technologies. In order to create a powerful XForm, you are better off being an expert in XPath than just knowing XForms notation itself. Similarly, half of your success is in the design of the data format of the document being edited.

To be honest, the Orbeon implementation is far from perfect. For example, it heavily depends on JavaScript / AJAX libraries  (in fact the worst possible choice: DOJO) and does not offer graceful degradation (yet). Nevertheless, it is the framework of choice during the first few parts of XML tutorials, because of its user friendliness and full-stack integration.

Summarizing: the upcoming posts prove the old criticism wrong by introducing a full stack XML framework running on the server side and explaining all XML technologies needed for the solution.

And again: stay tuned! Which means: install an RSS reader or use an online version! ;-) 

Summary of Rebuttal in 2007

In March 2007, Kurt Cagle wrote a rebuttal to the XForms vs Ruby on Rails post. There are some key points in this post that are fundamental for "Agile XML". Pay attention to the quote printed in bold font for example.

Here are some quotations from the post "xforms vs. ruby - a rebuttal (sort of)" written on March 30th 2007 by Kurt Cagle:

"Adriaan de Jonge's article Xforms vs. Ruby on Rails has created quite a stir in both the XML and Ruby communities, and for good reason. He asked a fairly important question - are XForms an also-ran technology that Ruby has managed to supplant?"

"My quibble with the argument is that to me Ruby is an apple, XForms an orange - or perhaps more accurately, Ruby is a framework, XForms is a systems component."

"[...]  regardless of whether you are working with XForms or Ruby or ASP.NET, your data models are likely to be considerably more complex than a single stream of static XML"

"The XForms architecture pushes the level of abstraction up a level. In this case, the components that you interact with on the page are not actually involved in maintaining the data model - only in changing it. This is a subtle distinction, but an important one."

"This is actually a pretty profound expression of Model/View/Controller architecture."

"XForms is useless for a fair number of web development tasks."

"[...] XForms applications are most likely going to be utilized precisely in those areas where Ruby won't be."

"Where XForms comes into its own is when you're dealing with data - lots and lots of data."

"Most of the clients that I deal with when building XForms applications are not, in fact, looking at building another community site."

"I personally think that the days of shrink-wrapped software are history."

"Increasingly, software is becoming oriented towards helping people with lots and lots of data get at that data more effectively."

"It actually works better in conjunction with something else, which I am increasingly coming to believe is an web-enabled XML database working with either XQuery or XSLT (preferably both)."

"XML has become THE language of data transfer."

"[...] in an XQuery/XForms/XSLT solution, you are quite literally floating in an XML sea, where XML coming from a collection or external server is only a function call away."

"XForms has taken off in those places where it's most suited, and this even before there's a native version of XForms sitting in a browser."

"I'd far more like to see XForms and Ruby on Rails rather than XForms vs. Ruby‚ and I suspect so would your customers."

And this is one of the comments on this article:

"Thanks for these insights. Adriaan's posting was impressive, almost intimidating, so it's good to have some balance from another web tech / XML guru. Here I was wondering if I needed to abandon XForms for RoR. (Incidentally, you keep referring to "Ruby" but I think Adriaan's argument was really only about Ruby on Rails.)

[...]

So there is a real value to being able to pick one framework and stick with it. Part of the value of RoR over XForms is that RoR provides the whole stack (or at least more of it).

Lars | July 11, 2007 08:15 AM"

Summary XForms vs Rails in 2006

In december 2006 I wrote down some criticism on XForms in comparison to Ruby on Rails. The current series of posts points out I no longer agree with my own old criticism. It is interesting to summarize the key point though, in order to get clear where we are right now!

Here are some quotes from the post XForms vs. Ruby on Rails written on december 24th, 2006:

"I lost my faith in XForms as a widely accepted standard supported by all browsers on all platforms."

"Rails is a so-called full stack framework."

"When I first saw source code for Rails, it didn't make much sense to me. "

"A large majority of software geeks make the world think that the main purpose of software is instructing the computer to perform series of actions. This is a crucial mistake. The main purpose of software is communication between people."

"Although very different, both XForms and RoR are solutions to the same flaws."

"Native XML databases are still an exception."

"Considering the additional effort required to handle the server side aspects of XForms, it comes nowhere near the RoR framework."

"XForms logic beats any other technique when used in XML documents with semi-structured nature."

"For someone with the knowledge and experience of a software architect, the simple tools in XForms can be the building blocks of a very advanced and intelligent application."

"A key design choice in Rails is to do every aspect of the app in Ruby and avoid writing even a single line of JavaScript or SQL."

"In my earlier XForms tutorial I learned that I can push the logical model way beyond anything I have seen in a browser so far."

"Subscribers of my weblog may have noticed that I'm not a big fan of AJAX but consider it a necessary evil for usability sometimes."

"Choosing open source software, it is easy to forget about the commercial aspects because it's free anyway."

"While I was waiting for XForms, the only thing I did with AJAX was to criticize it."

"Rails wins easily when it comes to innovation and buzzword compliance."

"XForms is more elegant than pragmatic."

"The XForms concept was born from a vision but it is being implemented like a mandatory school assignment. The key advantages of XForms have an academic nature. This is the exact reason why I like them myself. It is also the exact reason why it fails in the real world."

"Ruby on Rails is based on clear vision and goals and implemented accordingly."

"Ruby on Rails is a role model example for pragmatism."

"For me, right now, I prefer Ruby on Rails over XForms."

Answering mail #1

Selmer wrote:

I liked your division figure. There is just one little thing. Intuitively I assume that technologies near the divisor are more commonly used in all clusters: Sun, IBM and Oracle. Judging from the position of XML, I suppose you think otherwise? Or do you have a different view on XML?

(roughly translated from Dutch)

That is an interesting point. I think you're right that XML is commonly used in Sun and Oracle technologies as well. The picture says more about preference than actual usage though. I think the Sun and Oracle developers only use XML as a necessary evil in order to be able to communicate with "exotic" platforms like dotNet. But if they would have the chance, they'd use RMI over IIOP any chance they get.

The Oracle guys are a whole separate chapter. I think they have a very thorough grasp on relational modeling. I usually question their object oriented modeling skills though. And I think they are not keen on semi structured documents (XML) because they're hard to store in an RDBMS.

Your last question hits the key point: most likely I have a different view on XML. Using a little bit of XML for configuration, WSDL, SOAP or BPEL is not really intriguing. Especially not if the platform puts a lot of effort in abstracting away from underlying XML technology. What you'll see on this blog over the next few weeks is the exact opposite: I'll be abstracting away from the underlying platform and focus on the XML itself!

New Theme: Agile XML

The new series of articles have a common theme: Agile XML. This theme is also the new title of this weblog. At least it is more descriptive than my own name and it is a good prefix to have in the titles of the new posts. 

But what does it mean?!? Stop documenting and release untested code directly to the production server???

Most certainly not! In my definition, Agile is all about involving people in development processes. This means:

• Technical details should be hidden under the hood and just do their work properly.
• Formats are modeled after their real world purpose and implications; not after technical boundaries.
• Solutions should be open for change anytime; designs should never be fixed constants.
• Implementations are written to be read by people: both self-documenting and well-documented.
• Even XML technology can be combined with test driven development!
• The need for non-XML code is reduced to nearly zero for solution implementations; all requirements are handled by the generic infrastructure code.
• Full stack frameworks are preferred over custom integrations.

Tomorrow I'll introduce a first candidate for a full-stack framework that can compete with Rails...

Stay tuned!

Reevaluating XML in the Java spectrum

From an outsider's perspective, Java might seem a strange world with many developers with many different opinions. It might even seem chaotic and hard to manage. For example, some Java developers dislike XML while others adore it.

I think it is possible to divide the Java world into roughly three clusters of related technologies, each of which has its own share of followers: (this is only my opinion...)

As you can see, I put XML in the IBM cluster. Apparently the developers who don't like XML are in the Sun cluster. Not coincidentally the same cluster where Ruby and EJB are. I think there is a reason for this.

The older versions of EJB extensively used XML inappropriately and these developers associate XML with this wrong usage. Ruby on Rails answered these feelings by minimizing the usage of XML. Within the Sun cluster, they had a point. But looking a bit further than that, it seems that the value of XML is currently underrated. 

In my old post comparing Rails and XForms I argued that XForms was trying to find new solutions to old problems, where Rails is improving the old solutions to do the current tasks better. I think, Rails unintentionally inspired many Java developers to start doing questionable things with Java technology. (Like hardcoding things in Java because they are used to doing that in Ruby)

Now the Rails hype is over and started doing at least as much damage as EJB's XML abuse, it is time to clear up the mess and take a look at proper technologies. First of all, let's focus on web standards (most of which are XML based) and use technology that properly supports them... 

The next few posts cover XML technology, but keep in mind that the underlying platforms better fit in the IBM cluster than in the Sun cluster!

The Sun, IBM and Oracle clusters are the opinion of the author. There is no official source claiming there is any truth in this division.  Most probably, the companies themselves will disagree. 

XForms tutorial part 5: The Restart

Due to popular demand, it is time to reevaluate the value of XForms and make a new fresh start with the tutorials. I have to be honest about the first four parts... Not only are they a bit lengthy and unfocused... I also lost the source files and examples when my hard drive crashed and I did not make a backup.

I was a bit reluctant to rewrite the samples because many of them are outdated. But taking baby steps, I can reproduce the interesting parts in a way that fits the year 2008! This means the Mozilla XForms plugin is replaced by server side solutions like Chiba and Orbeon. It means shorter posts covering one clear subject. And last but not least: it means covering the right subject under the appropriate title.

As you might have read in the early parts, to learn XForms, you need to know more technologies than just XForms. So from this point on, you'll find short tutorials on:

• XML and namespaces
• XPath
• XML Schema
• XML Events
• XSLT
• XML Pipelines
• XQuery
• and maybe if there is some time left... XForms!

To start keeping promises, I won't make this post too long: please do subscribe to the Atom feed of this Weblog and keep an eye out for upcoming posts!

Tags: XForms | XPath | XML