Re: SV: Tim Bray on "Which Technologies Matter?"
Hi Len Len said: > For those who don't follow markup history: automated > typesetting systems drove markup to emerge as the > progenitor of what we have today. The concept has > been around for quite some time. The name belies the > origin. Didier replies: And this is maybe why XML used to encode "rendering languages" is doing so well. So if we recap we have typesetting --> markup ---> SGML ---> XML some further thoughts.... As you know, it also seems that we are surfing on "XML as an accepted standard" to be used for other usages than rendering. XML ----> rendering |--------> data |--------> procedure calls XML used to encode data, to encode rendering objects, to encode procedure calls. XML seems to evolve into a general "message encoding" medium. We can also say that XML is slowly evolving into a framework. Part of this framework is a good refined version of something more complex. In that sense we reduced the complexity and came out with something more usable and simpler. Thus, we applied the Occam razor and subscribed to the "less is more" philosophy. Some other parts of this framework sit between two chairs, suffers from an incomplete learning curve, or more simply suffers from the "camel effect" . For instance, if XML is used to encode data, why XLINK is using a visual attribute to indicate if the referred document is to be displayed or not. The whole notion of "display" refers to rendering languages. Thus Xlink sits between two chairs. To keep thing straight I would use the hierarchy mentioned previously as an underlying thought structure when designing or modifying new XML framework elements. however I would use the following order 1) data 2) procedure 3) rendering Procedure is included here, not because I like it, simply as a matter of fact, it is, for good or evil, part of our XML world. Thus, when designing a part of the XML framework I would say: a) it is a framework b) is the basic tool we are adding or modifying do not mix data and rendition. For instance, linking data do not imply that we render it. c) what is the intent of the new construct (render, structure data, call for an action) and try not to be between two chairs and stick to one domain and let other tools perform the transformation or resolve the impedence mismatch. d) Try as much as possible to remember that "less is more" and remember that the fools that ignore history repeat the same mistakes. ADA or PL1 didn't made it because they where to complex. C made it because it was simpler. In one word: "focus". I personally think that XML used to encode data as done by modern SQL DB or XML native DB is a lot better than using XML as an RPC marshaling protocol. But this is my taste and I am fully aware that a hammer cannot be used to fix everything. However, XML as used today to encode either a procedure call or data leads to interesting side effects. And this particularity is brought by the XML framework. We gained something new in the process. Let's take some seconds of our time just to consider it. data ---> rendering or procedure ---> rendering For the last element, and because of the particular tools included in the XML framework, we can say that a procedure could be either processed or rendered. For instance, let's say that I have a SOAP call encoding the following call: post_transaction (string). This latter expression could as well be encoded as a simple HTTP transaction but, because the gorillas need us to depend on them, let's say that the developer is forced to encode this as a SOAP call. Let's say that the string contains an invoice which is an XML version of an EDI transaction. It is so because of the hierarchical nature of XML and because the number of lines in the invoice is variable. To encode the invoice as a structure is to rigid (except if the notion of variant or union is supported) and this is why we used a string to contain the XML document. This XML document could be transformed with an XSLT style sheet and rendered. Thus we have: procedure call ---> XSLT ---> rendering objects This could be the case for a more rigid call like: do_a_withdrawal (amount) - amount is a real number. Again, if the call is encoded as a SOAP call, we can transform this procedure call into a rendering object without any intervention from a procedural construct. We gained something new with the XML framework: the capacity to transform a data structure into an other or to render it without any procedural code. We can also transform a SOAP document containing several SOAP calls into data or into a rendering object. Thus to transform procedure calls into rendering objects without the intervention of a procedural language. again: procedure call ---> XSLT ---> rendering objects (no procedural code in the process to resolve the impedence mismatch between rendering objects and data contained in the procedure call and the rendering objects - This implies that in the future I may have either a human being to perform the procedure, hence having the procedure and data transformed into rendering objects, or to get an automata to perfrom the action. The call would be same for both - something like pay(invoice) - the automata may follow my rules and pay the invoice automatically or I may get the invoice rendered and manually pay it). Off course the XML framework cannot resolve the independence mismatch with all the legacy storage structures and this is why we still need procedural constructs. Also the actual XML framework tools are insufficient for certain tasks. However, we still have to explore a lot what we can do this framework, and this is what I will do in Didier's labs. I'll keep you informed. cheers Didier PH Martin  you know the joke: a camel is a horse designed by a comity :-)  This is the basic rule of monopoly: own all the lands and charge for it. And if you own the lands, do not let them go :-)  if we consider that a rendering object could contain other ones - hence a hierarchy of rendering objects.
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format