In a previous entry, I argued on the need for native XML support in the Java programming language. During the last couple of days, there have been some interesting reactions which I would like comment on.

XML Schema issues
Fred is worried about how we would go about validating an XML instance document against its corresponding schema. As I said in my answer to him, it should be possible to provide the schema and an optional error handler as further arguments to the Document constructor. Another solution to this would be the one proposed by IBM's XJ project as pointed out by Steve in his blog.

Ignoring annotations for now, the most interesting tangible stuff on adding XML to Java is IBM research's XJ, which looks very cool indeed. Automatic import of XSD files, inline xpath operation. The latter is what is nice. I bet you could implement a SOAP stack there nice and quickly. Mukund Raghavachari, the project lead, contacted Ed and I to say that a new release is coming soon. But will XJ become Java7? Oh, there are some interesting politics there. Let's see, "will sun hand over innovation of the Java language to its main competitor?". Probably not, no. Maybe it's time to fork the language.

XJ features are quite impressive and the project is a first step into the direction I expressed. The good thing is that since all the binding work is done a compile-time there is no need for runtime error handlers. Letting politics aside, I think that with some polishing, it could even make it into Mustang, disregarding the advertised limitations, of course ;)

Jokes aside, let's rewrite the purchase order example using XJ. Furthermore, let's say that the related purchase order schema called po.xsd is stored in the com.mycompany.myproject package. The code would now look like this:

//Tell the XJ compiler to use the po.xsd schema.
import com.mycompany.myproject.po;
...
//Retrieve the purchaseOrder object from the XML instance document
purchaseOrder po = new purchaseOrder("po.xml");

//Retrieve all partNums and compute the grand total for the purchase order
double total = 0;
Sequence<item> items = po[|//item|];
XMLCursor<item> itemCur = items.iterator();    
while (itemCur.hasNext()) { 
   item it = itemCur.next();
   System.out.println("partNum:" + it[|@partNum|]);
   total += new Double(it[|./USPrice/text()|]);
}
System.out.println("Grand total = " + total);

We still have some metalevel clutter with the Sequence and XMLCursor stuff. Furthermore, XPath has to be supported natively by the compiler as well, which is not necessarly a good idea in my opinion. I would prefer to use a dotted notation for navigating through the XML element hierarchy. Aside from those details, the code looks waaaaay nicer and is much more concise than the other two DOM alternatives. I'm eager to see how the new release of XJ will look like.

IDE Code Completion issues
Someone raised the interesting issue of how IDEs may continue to provide code completion features if native XML support was to be included in the Java language. As seen above, the xjc compiler not only compiles conventional Java code as do all other Java compilers, but it is also able to process XML schema and dynamically build the corresponding Java classes. The XJ compiler seems to provide some sort of implicit O/X mapping at the compiler level. So, as soon as an XJ file is compiled, all the typing information contained in the XML schema is available for use. The only thing is that with XJ you cannot invoke methods on the reified XML elements. The only way to access their children or attribute values is by using XPath expressions. As I see it, this is a big limitation of the current XJ release.

XML as a programming language
To me, providing native support for XML in the Java programming language and considering XML as a programming language per se, are two different things which we must be very careful not to mix. In a recent blog entry, Steve argues that there is a natural syntactical bridge between XML as a data format and XML as conventional code by using a Scheme clause analogy. He says:

So you cannot say that code-in-XML is inherently wrong, as there is clearly a two-way transform at the syntactic level from an XML document into a scheme clause, and since scheme is an elegant and powerful language, so there is an elegant and powerful way to work with XML, within a representation of the document itself.
All you need therefore, is (1) an appropriate expression evaluation engine and (2) a representation for XML that you are prepared to work with. It is unfortunate that classic-XML is not the best structure for humans, S-expressions are neater once you get used to them -but spend enough time and XML becomes readable too. All that leaves is the appropriate expression evaluation language. No, I dont think water is it either. It looks a bit LISPy, but seems to be trying to do that inside content markup.

OK, now I'm worried. I didn't say that code-in-xml is wrong, just that in my opinion XML is neither suitable nor intuitive for this kind of usage and that it has not been invented for that purpose. Scheme is an old horse, on which I haven't been riding much over the last couple of years, so I'm a bit rusty. If memory serves me right, fully nested notation might well remove tricky ambiguities and is well suited for a computer to process but it is definitely not intuitive at all to us human beings because this is not the way we are used to process information. I don't question the expressive power of Scheme or any other similar functional languages for that matter, but please tell me whether it is easier for a human being to understand "the cat drinks milk and the dog eats meat" or "and drinks the cat milk eats the dog meat". Sorry, it wasn't fair, I forgot to include the necessary parenthesis without which all these words don't make any sense at all since all the contextual information is lost. The correct sentence would look like this: "(and (drinks (the cat, milk)) (eats (the dog, meat)))".

To me, what really counts is that we can write programs in languages that most closely ressemble our because WE are programming those machines and not the other way around (letting the Matrix philosophy aside, of course). Since the dawn of computer sciences, people seem to recurringly come up with new ways of making it easier for the compiler to process software code instead of making it easier for humans to create software. I don't care whether the compiler will have a hard time compiling my stuff, what I do care about is that I can write software for my customers in a language that is most closely related to mine and not to the computer's. I don't see why we should always have to lower ourselves down to the computer level instead of bringing the computer up at our level. At the end of the day, what I really want is to create solutions (i.e., software) for solving problems (i.e., customer needs) and this can only be done efficiently if all people who take part in the creation of these solutions have the right tools and languages that are best suited to their needs and that very closely mimic the way they communicate together. In my opinion, 4GL and 5GL languages are part of the key to efficient, productive and focused information system development.

In one of my recent comments to Steve Loughran, I mentioned that Java 7 (aka Dolphin) native XML support could provide an elegant solution for bridging the gap between the Java programming language and XML. I have already argued that I don't see XML imposing itself as a WATER-style programming language. I think anyone can understand what I mean when looking at the WATER and Java comparison page provided by the WATER folks. The following "XML programming" code is worth a million pictures.

 thing.<set the_cache=<thing/>/>
 <defmethod cache_it expr=required="ek_string">
      <if> the_cache.<has_key expr/> 
           the_cache.<get expr/>
 	 else
 	   <set val=expr.<execute/>>
                 the_cache.<set_value expr val/>
                 val
             </set>
      </if>
 </defmethod>
 <cache_it 2.<plus 3/> /> 

Steve, please tell me that Alpine is NOT headed into that direction.

Assuming that Alpine's goals are legitimate and considering Steve's assumption that there is no good solution for efficiently working with XML today, let's delve a little bit into the current state of Java and XML programming in order to discover what the ideal solution could be and how I would like to see native XML support implemented in the Java programming language.

One of the first attempts at simplifying DOM programming in Java was tackled by the JDOM guys, whose main goal was to provide a much simpler programming interface for Java programmers to manipulate XML files. Admittedly, they have been very successful. But, even with JDOM, we are still programming at the metalevel since we have to use methods such as getAttribute() or getChildren() in order to manipulate the content of an XML document. In order to illustrate the different ways of handling XML data using DOM, JDOM or Dolphin's XML native support, let's take the infamous purchase order XML document (po.xml) as an example (repeated below for convenience) and show how to:

1. retrieve all partNum attribute values of the item elements; and
2. compute the grand total for the whole purchase order using the text value of the USPrice element.

[Note that Dolphin's work on native XML support is still under research. So the code I provide is just a tentative on how I think such a native support would look like.]

<?xml version="1.0"?>
<purchaseOrder orderDate="1999-10-20">
   <shipTo country="US">
      <name>Alice Smith</name>
      <street>123 Maple Street</street>
      <city>Mill Valley</city>
      <state>CA</state>
      <zip>90952</zip>
   </shipTo>
   <billTo country="US">
      <name>Robert Smith</name>
      <street>8 Oak Avenue</street>
      <city>Old Town</city>
      <state>PA</state>
      <zip>95819</zip>
   </billTo>
   <comment>Hurry, my lawn is going wild!lt;/comment>
   <items>
      <item partNum="872-AA">
         <productName>Lawnmower</productName>
         <quantity>1</quantity>
         <USPrice>148.95</USPrice>
         <comment>Confirm this is electric</comment>
      </item>
      <item partNum="926-AA">
         <productName>Baby Monitor</productName>
         <quantity>1</quantity>
         <USPrice>39.98</USPrice>
         <shipDate>1999-05-21</shipDate>
      </item>
   </items>
</purchaseOrder>

Using DOM, the Java code would look like the following:

import org.w3c.dom.Document;
import org.w3c.dom.Element;
...
//Retrieve the Document object
DocumentBuilder fact = DocumentBuilderFactory.newInstance().newDocumentBuilder();
Document po = fact.parse(new File("po.xml"));
Element root = po.getDocumentElement();

//Retrieve all partNums and compute the grand total for the purchase order
double total = 0;
NodeList children = root.getChildNodes();
for (int i = 0; i < children.getLength(); i++) {
   Node node = children.item(i);
   
   //Find the items child element
   if ("items".equals(node.getLocalName())) {
      NodeList itemList = node.getChildNodes();
      for (int j = 0; j < itemList.getLength(); j++) {
         Node item = itemList.item(j);

         //Get the partNum attribute value
         NamedNodeMap attrs = item.getAttributes();
         System.out.println("partNum:" + attrs.getNamedItem("partNum"));

         //Find the USPrice child element
         NodeList itemChildren = item.getChildNodes();
         for (int k = 0; k < itemChildren.getLength(); k++) {
            Node child = itemChildren.item(k);
            if ("USPrice".equals(child.getLocalName()) {
               total += Double.valueOf(child.getNodeValue()).doubleValue();
            }
         }
      }
   }
}
System.out.println("Grand total = " + total);

I'll spare you the comments as this DOM code makes an excellent job at discriminating itself by screaming out loud "Please don't use me" to whoever watches it!

With JDOM, things are several orders of magnitude easier as the provided methods for browsing through the hierarchy and for gaining access to the raw meat of the XML document are less convoluted. Plus, using JDOM, you get neat hooks that allow you to take org.w3c.dom.Document objects and use them to build the corresponding JDOM hierarchy.

import org.jdom.Document;
import org.jdom.Element;
...

//Retrieve the Document object
Document po = new SAXBuilder().build(new File("po.xml"));
Element root = po.getRootElement();

//Retrieve all partNums and compute the grand total for the purchase order
double total = 0;
Element items = root.getChild("items");
Iterator itemIt = items.getChildren().iterator();
while (itemIt.hasNext()) {
   Element item = (Element) itemIt.next();
   System.out.println("partNum:" + item.getAttributeValue("partNum"));
   
   total += Double.valueOf(item.getChildText("USPrice")).doubleValue();
}
System.out.println("Grand total = " + total);

As the above code shows, JDOM definitely fulfills its goal of providing a simpler API for DOM programming in Java. However, JDOM still requires developers to program at the metalevel and this is a big problem in my opinion as we cannot completely concentrate on solving the problem at hand. More on this later...

Finally, as I see it, there are two ways of having native XML support in Java: explicit support similar to Ecma's E4X (ECMAScript for XML) specification and implicit support where the programming language shields you from seeing all those angle brackets clutter. The latter is my preferred one. Thus, the way I would like to see native XML support to be implemented would be some sort of mix between XPath and native data binding built into the Java programming language. Stefan Tilkov should interpret this as my way of seeing "native" O/X mapping built into a programming language such as Java. This native support should allow one to manipulate the real business entities directly instead of their metalevel counterparts. I would really like to not having to deal with the document-children-node-element terminology any more. I would like to solve business problem, and thus, it would be far more productive to have a language that allows me to develop solutions using business terms and not terms made up by some bunch of geeks hiding deep in a development cave. Looking at the code below, this is what I call ease of development! I'm quite sure this can be taken a little further but in comparison to the two previous solutions, I see this as a kind of developer's Graal.

//Retrieve the PurchaseOrder object
Document doc = new Document("po.xml");
PurchaseOrder po = doc.getPurchaseOrder();

//Retrieve all partNums and compute the grand total for the purchase order
double total = 0;
for (Item item : po.getItems()) {
   System.out.println("partNum:" + item.getPartNum());
   total += item.getUSPrice().asDouble();
}
System.out.println("Grand total = " + total);

The solution could even be better in terms of performance if we let aside the object-oriented tight encapsulation dogma for a second and use attribute access using the traditional dot notation instead of having the JVM create a costly activation frame upon each method invocation. Things would look like this.

//Retrieve the PurchaseOrder object
Document doc = new Document("po.xml");
PurchaseOrder po = doc.getPurchaseOrder();

//Retrieve all partNums and compute the grand total for the purchase order
double total = 0;
for (Item item : po.items) {
   System.out.println("partNum:" + item.partNum);
   total += item.usPrice.asDouble();
}
System.out.println("Grand total = " + total);

Agreed, six activation frames less won't change much in this small example, but I'm quite sure we could gain a substantial amount of time when processing heavy XML documents. Imagine a way "à la XPath" to access a value three levels deep in just one line of code. For instance, po.items[1].productName would return "Baby Monitor". Great, isn't it?

And your next question might be how we come up with the PurchaseOrder and Item class definitions? In my opinion, using on-the-fly byte code generators can do the job pretty well. For instance, when the compiler encounters the Document object creation, it shall dynamically create a new class definition for the root element (purchaseOrder) and populate it with all the necessary business methods for enabling the retrieval of its content (getOrderDate(), getItems(), etc.). In addition, the compiler should also dynamically modify the Document class definition to add a method (getPurchaseOrder()) for retrieving the root element as an instance of the newly created class. This should remove the need for having to explicit cast the root element that would be returned as an Object. Then, the compiler may freely proceed with the dereferencing of the newly created PurchaseOrder instance as it now has everything it needs to go on. I'm quite sure there are other solutions as well, though, but I find this one quite developer-friendly.

Now, which solution do you guys prefer? Don't tell me the first or the second because I won't believe you. Imagine the potential of the third solution for programming SOAP (if it still exists in 2007 of course) or for programming against any other XML-intensive framework for that matter. Personally, I see XML native support in Java as a way to finally let the IT division focus on its primary goal, which is to support the business of the company and let developers and business guys talk with a compatible vocabulary. Today, a non-negligible number of IT guys are acting as if the company's primary business was IT. They come to meetings with their convoluted geekie dictionary and take a great pleasure at mystifying information system development and making it seem as if it was like climbing Mount Everest right after coming back from K2. What those guys don't understand is that their primary role is to develop information systems for supporting the business of their company. In order to achieve this, they sure need frameworks and APIs that are way simpler to use as they are today. To me, ameliorations, such as the one proposed by Dolphin, definitely go into that direction and sort of makes Java become a true 4G programming language by getting closer to the human natural language and getting away from that silly metalevel. This would clearly benefit everyone. From the developer who would certainly understand much more quickly what the code does (or should do) and which business concerns are implemented in the code, to the business guys who would finally share a common vocabulary with the development teams. Let's stop (or at least diminish) programming at the metalevel as 95% of the time this practice is not productive at all and let's finally share a common vocabulary with business folks. I'm sure that would definitely contribute to repolish IT's image and recover from the bad press that our sector has been receiving over the last couple of years.

Related entries:
Native XML Support in Java (Round 2)
HP's "Rethinking the Java SOAP stack" should be rethought
"Alps" Defender Steve Loughran strikes back

Continuing my explorations in the richness and diversity of the Dorset House library, I have put my fingers on Dorset's latest jewel by Alan M. Davis' titled "Just Enough Requirements Management, where software development meets marketing". As always with Dorset's titles, this has been a very enriching and eye-opening reading experience. A must read for people aiming at respectable requirements management responsibilities! Here is one memorable quote from the book, which I think somehow illustrates the nature of its provocative content: "If you believe that you know the requirements better than the customer, you are part of the problem, not the solution." My 10-horseshoes review follows (also available at Javaranch.com):

The primary goal of an information system is to provide a solution to a given business problem. The development of such systems usually involves people from at least two sectors, such as the IT sector as the solution provider and the business sectors for which the software solution is being devised. Since the needs are usually expressed by the customer, it becomes immediately clear that one of the most critical phases of the software development lifecycle is the requirements management phase. Failing to efficiently manage that phase can have disastrous consequences as the implemented solution might not correctly fulfill the customer's needs. Alan M. Davis, an award-winning professor, author and entrepreneur, contributes very useful and successfully applied requirement management techniques for effectively performing and managing requirements elicitation, triage, specification and change. Davis argues that one of the main points to focus on when managing requirements is to allow computer-savvy IT actors and computer agnostic business actors to understand each other by using a language that can be understood by both parties and that can be easily adapted to the relative complexity of the problem at hand and to the available resources for solving that problem. If you repeatedly find yourself having troubles managing requirements for your information system development projects, or if you have a hard time communicating with your marketing or business departments or even with your customers, this book will undoubtedly make your day. If successfully applied, Davis’ techniques will definitely have a highly positive impact on both your budgets and the quality of the delivered solutions.

In my last entry, I shared an opinion on why HP scientists Loughran and Smith should revamp a little bit their paper, called "Rethinking the Java SOAP stack". Believe me Steve, my intention was not to be brutal as you seem to imply. If this was the case, I could have been much more caustic, trust me on this. I apologize if you interpreted my thought sharing as such. My intention was just to provide an overall view of the different opinions about potential solutions for fixing the problems at hand and to explicitly state that there is no white or black solution for dealing with the kind of issues you are tackling.

Looking at your example, I admit that I can read your XML document and understand it pretty well. But the problem you mention, i.e. the fact that machine-generated XML files are not human-readable, is neither a problem of JAX-RPC nor any other high-level technology that uses XML as its underlying wire format. The problems comes from the way these generators have been implemented and the way they have been instructed to spit out XML. It's not a technology problem as you seem to imply, it's an implementation problem. The technology in itself is not bad, but maybe not enough time has been invested on implementing it as it is too often the case in this world whose main concerns are ultra-short time-to-market and ultra-high productivity.

So what you propose is to get rid of those generators because they are not flexible and configurable enough and to do the job ourselves by hand. Well, I admit you have put the fingers where it hurts and you get the point. But this does not mean that we have to restart all over again. The way I see the Alpine solution today is very much similar to "Do not pass Go, do not collect 200". Why would I be happy to have to hand code the communication payload for all my messages? Personally, I think that my neurons are much better served for solving my customers' real business concerns, which cost them tons of dollars instead of perpetually reinventing a 50-years-old wheel that has been rolling its way quite acceptably for the last couple of years.

As you say, resistance is good because it means that your stuff is being read. I can't agree more as we can only ameliorate what exists, so one has to start somewhere and build upon the constructive critics people care to share. I'd be happy to see where Alpine is headed. The only thing I can say right now is that I just hope that you are not headed towards the "Alps" in the picture you provided because unless the picture has been taken from the Italian side those are not the right Alps. The only genuine Alps I know of are the Alps I'm living in here in Switzerland and I can assure you that I very much like them. And regarding my name, rest assured that I'm not a big fan of anonymity. Val is just how people I know usually call me, and my real name is Valentin Crettaz :) I'm happy the presentations are done now.

In their "Rethinking the Java SOAP Stack" paper, HP scientists Steve Loughran and Edmund Smith are throwing down the gauntlet. Their intent of creating Alpine, an open-source SOAP stack heavily based on XML, is viable, yet somewhat clumsy. Some opinions have immediately been voiced in favor and against Loughran's and Smith's proposal. Moreover, people like Joseph B. Ottinger and former JAX-RPC partisan Richard Monson-Haefel are not really tender either and recently wrote incendiary blog entries against both JAX-RPC and the Alpine alternative. In order to federate all these discussions, Floyd Marinescu has opened the debate on TSS and is asking for feedback. All this fluff proves one thing for sure: ground-breaking changes are needed urgently!!!

As far as I'm concerned, I'm really skeptikal about people willing to deal that much with XML for getting that kind of job done. Personally, I think that dealing directly with XML is counterproductive in some cases and I like having a 3G programming language like Java or C# doing all the XML chores for me. It's not that I don't know XML. In the contrary, I know XML too well for realizing that I don't want to have to deal with it directly all the time. Most of the paper is centered around the fact that the Object-to-XML (O/X) mapping is not a trivial task. This is undeniable and I do agree with that (the development of JSR 31 took more than three years to complete). As a side note, the WATER folks think they have THE solution with their WATER language, which is some kind of XML programming language (or so they think). In adequation with the official XML goals, I have never been of the opinion that XML has been designed for becoming a programming language and when I see horrible things like this I'm even more convinced. Side note closed. The bottom line is that XML is becoming more and more complex everyday with the 100+ specifications out there and simplifications are much desired.

One of the greatest omissions in this paper is the lack of reference to the freshly rebaptized JAX-WS (ex JAX-RPC 2.0) specification, which has been jointly developed with JAXB 2.0 and whose goal is to drastically ease the development of Java web services. It is worth pointing out that Loughran recently gave in that they lacked experience with the new specification, and thus, didn't want to comment on it. As JAX-WS spec co-lead Marc Hadley legitimately pointed out in his blog:

However the JAX-WS EG recognized that in some (or many, depending on your perspective) cases working at the XML layer is useful/desirable and so we added a couple of XML-centric APIs that completely bypass the XML<->Object layer of the stack: Dispatch and Provider.
Dispatch is the client side API and uses the generic functionality introduced in J2SE 5.0 to offer an API that allows the developer to choose their abstraction. Developers can work with entire messages or message payloads either using XML APIs or using pre-cooked JAXB classes.

What this says to me is that JAX-WS already fulfills Alpine's first design goal, which is to "Stay in the XML space as much as possible", while still giving developers the choice to switch to Java binding solutions whenever they feel the need to. When you come to think about it, this is a very flexible approach. As everyone knows, there is no silver bullet, any problem can be solved both efficiently and inefficiently, and thus, it is up to the developer to decide whether XML is more appropriate than Java binding for solving the problem at hand. JAX-RPC 1.1 was on one extreme where Java binding and tons of other bad stuff were required. Alpine goes on the other extreme in that it only allows developers to work on the XML layer. And now, JAX-WS bridges the two approaches by letting the developers choose which solution is best for them in a given context. In my opinion, giving the developers the responsibility of choosing which solution is the most appropriate is a very good thing. Moreover, it requires the developers to really think about what they are doing instead of simply relying on the underlying tools generating the not-always-that-efficient plumbing code.

Another claim the authors make is that basically WSDL is too complicated to use. This was true for WSDL 1.1. However, WSDL 2.0 is not far away with its load of improvements and novelties. Moreover, by using annotations from JSR 181: Web Services Metadata for the Java^TM Platform, such as the golden @WebService, web services developers will have much more power over the WSDL generation process. Just have a look at Frank Sommers' Three Minutes to a Web Service and Recent JDK Features Ease Web Service Development articles on Artima.com to get a feel of how easy it will be to develop web services.

Another great improvement that JAX-WS will provide is the support for client-side asynchronous operations using the Java 5 Concurrency API Future interface. This interface should help Steve and Edmund take care of their multi-megabyte CAD file transfer issues ;)

No hard feelings guys :) Just remember that everything is neither black nor white, there is always a gray shade solution inbetween that will solve your problem.

I recently discovered Lexico's CleverKeys software, which allows you to lookup a given word in a remote dictionary (like www.dictionary.com) or thesaurus (like www.thesaurus.com) in one single step.

The installation ran flawlessly in about 10 seconds. When you launch the tool, a small icon appears in the system tray, through which you can set some preferences. Then you can select a word at any time in any program and press Ctrl+L. A browser window is opened and the word you selected is looked up within the dictionary database. Agreed, this is no revolution, but it's a nice shortcut that I use very often.

A nice addition would be to enable the search to occur in several user-configurable dictionaries at the same time, which is not possible in the current version. Moreover, Linux users will have to wait patiently as only Windows and Mac versions are provided. Does anyone know of a similar tool on Linux?

"Seeing What's Next" by Clayton M. Christensen, Erik A. Roth and Scott D. Anthony is an eye-opener for anyone who's striving hard to decrypt the dynamics of industrial markets and to understand how and under which circumstances they evolve. If you are looking for scientific techniques for predicting market changes, you should consider this book! My 9-horseshoes review follows (also available at Javaranch.com):

Having innovative ideas is one thing. Developing, positioning and selling those innovations are completely different matters, which necessitate a sound and well-researched knowledge of the market. How many times have you told yourself "Wow, this is a great thing, I'm pretty sure people need that"? How many times have you realized that the idea you had was not the next big thing anymore because the market changed in unexpected ways and you were incapable of correctly interpreting those stimuli and adapting yourself? In "Seeing what's next", the authors adopt a highly pragmatic approach and teach you how to use the theories of innovation for listening to the market and its actors in order to correctly interpret and capitalize on the signals it is sending. Using real-world case studies from five large industrial sectors, such as telecommunications and health care, they show you how to decorticate macro and micro facts that happened in the past in order to help you predict how your industry is expected to change in the future, how to come up with highly inventive business models and how you can make your pioneering company become tomorrow’s market leader. Small print for mystic readers: This book is based on sound scientific theories. It is not a crystal ball and it does not provide any stock buy/sell recommendations. This book will help you tune all your senses to the correct frequency for listening to market signals in a productive and static-less way.