Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: constructive (was RE: Markup perspective not c
 Hi Simon Simon said: I'm not sure why creating XML "created the situation". Before XML, developers had to think about how to exchange and store their information, and after XML, developers still have to think about how to exchange and store their information. Didier replies: Yes they used RPC and what made RPC useful is that the impedance mismatch between the language natural construct and the problem namespace is minimized. The problem RPCs encountered was that there where common ground (CORBA vs. DCOM). As a Pro for RPC is the recognition that productivity has to be improved or maintained. This is why, an RPC resolver or marshaller was automatically produced. The con was that since the RPCs where developed in times when statically typed languages where common usage, dynamic data structure was out of question. What made XML appealing for developers is that capability for XML to be more flexible and allows dynamic definition of hierarchies. The con for developers is the lack of sophistication of the tools since they had to back to the 50s (and probably more than that) and had to parse the document in order to do something with it. A better solution would be that the parsing is performed automatically and that the document's content is accessible both at the syntaxic and semantic level. The current state of the art is that only the syntax is available through the DOM. There is still more overhead than a simple RPC. So, the conclusion is simple enough, developers are taking the more sophisticated tools. It is like computer users. I still remember people saying that what we where showing them at Xerox PARC was not doing more than mainframe terminals. There where right, it was not doing more it was simply making the user's life more comfortable and a system more easy to use. Guess what people selected the mainframe terminal or the Xerox PARC way of doing things. If we where thinking to address their needs and provide good tool (I mean something more sophisticated than parsers) then we would probably get a positive response. I am wondering if the community is not like the guys who where telling me that the mainframe terminal where doing the same thing as my Xerox dorado station. Simon said: The only thing that's changed is a common syntax (now markup) for some of that information. I don't see how that creates a responsibility for markup to do the rest of a job that properly belong with developers close to the specific tasks that need to be solved. Didier replies: Yes but the tools to manipulate the document content or the information contained in the documents are very poor. A parser is not what we can call "state of the art". It is only the first step toward more sophisticated tools. Simon said: Perhaps in the enthusiasm about solving one problem (syntax) some folks thought that they weren't going to have to work anymore, but I don't think that's a problem for XML. Instead, by attempting to solve all these developer problems, something you apparently want to continue doing, we've added all kinds of new problems to XML (and the W3C's use of "XML" in spec names adds to the perception that XML itself has the problems.) Didier replies: No I am not attempting to solve all developers problems just a subset. And I guess you are right when you say that folks where thinking that they finally got the magic wand. This was part of the irrational exuberance, at lot of people lost their common sense for some times :-) My point is, instead of following the RPC path, if we where: a) offering tools allowing access to the syntaxic and semantic level of a document. We created element and attribute objects, why not objects having the element's name. Just examine with attention the rendering languages and you'll notice that most of them are defining hierarchies of objects and these object have properties. We are talking here of visual or aural objects and these objects are not called elements but lines, rectangles, circles, forms, etc... So, if we created elements and attribute objects mostly for statically typed language why not create semantic objects for dynamically type languages like java or ECMAscript. Gee we did it back in the 70s with smalltalk. Are we getting more brain damage as time passes? Simon said: It's time to stop solving developers' problems generically, and let them solve the problems themselves building from only a basic syntactic framework - if and only if the framework is appropriate to their problem. XML is not a magic wonder-glue for programming. Didier replies: This is what they do using XML as a framework to define a marshalling language. They are using what they know because they have no better offer. They looked at XML, saw a meta language that allows to create domain languages and they created a domain language: a marshalling language. If Jon and al. are having some success with their proposal of business documents like invoice, catalogs, etc... They will need the proper tools to extract the semantic information to help the developers resolve the problem not create new ones by asking them more work than they have to do today. You know, some centuries ago the request from the people for more bred got as response from the queen "if they have no bred, they just have to eat cookies". Guess what happened :-) As the guys who said that our Xerox Dorado was doing the same thing as the mainframe terminals learned, people will seek the solutions that answer their needs. Cheers Didier PH Martin 
|
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
|
|||||||||
