[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: constructive (was RE: Markup perspective not cod
Hi Simon Simon said: At some point polarization is necessary. Constantly aiming for consensus and insisting that all conversation lead to consensus is an excellent way to stifle diversity by keeping genuinely conflicting viewpoints from surfacing. There's a lot of nastiness in the XML technologies at this point, and I believe the conversation should reflect the technology. Didier replies: I agree that the actual state of the XML framework is quite messy and needs the same spirit and will that XML got at its beginning when it tried to simplify SGML. Is W3C the right organism for that? I doubt, W3C is unglued a mechanism that leads toward more complexity. Is Schumpeter right and do we need "constructive destruction"? maybe the technology can evolve by starting a new organism. This said, my point is that the polarization between programmers and XML authors is not leading to constructive matters, we attack the people not the ideas. We should be critic constructively the ideas not the people. I do not advocate forced consensus but good manners and respect toward people. Simon said: If there's a genuine conflict - and I believe there are many at this point - I think it's far better to air them (and strongly) than to leave them festering. It may in fact be time for division into smaller groups where consensus is achievable, but I think we need to find out what those groups are before we can find our way into them. Didier replies: I agree that different point of views have to be debated. Let's come back to ideas for a moment. If we want to help the developers using procedural code, we need to provide them constructs that make sense to the problems they have to resolve. Here are some requirements: a) That the infoset is presented not as a collection of elements and attributes but as "gizmos" (1) having the elements name. To be debated, do attributes are to be considered as "gizmos'" properties? The goal is to make possible the process of XML documents with constructs like account.balance(2), not a bunch of functions just to access the info that other languages do with few constructs. If I ask people if they want to pay more than what they are actually spending they will say no if this is the same product/service they already have for less. It would be foolish to think that people would spend more. But often in this list I read messages saying that yes they would spend more. I can just say that, in the real world, this behavior is not necessary nor useful :-) So, requirement (a) is not actually fulfilled and this leads to other solutions not leveraging the actual strength of XML structures (even if it uses the same syntax). b) That programmers have access to the different level of information extracted from an XML document. For the moment, we fulfilled the lowest levels at the syntaxic level but still do not provide useful tools for 80% of the problems resolved by developers. When developers are using a Perl, C++ or visual basic program they DO NOT HAVE TO WRITE NOR HAVE TO USE A PARSER. They are using function, procedures and variables. And the more popular tools are the ones following the Maupertius principle (3) Conclusion: people tried to fill the gap. So, can I ask the community to mind the gap and not polarize but use their brain to listen to the needs and try to find a good solution. If somebody is thirsty and lost in the desert I can either a) help him/her find water b) give him/her some water c) deny his/her needs Actually, I read a lot of messages using strategy (c) instead of trying to respond to a _concrete_ need. The real question is now. What are the _concrete_ alternative solutions we are proposing to these people. (1) I am using the word "gizmo" since some seems to have an alergic reaction to the word "object" and I do not want to trigger hypothalamic responses. (2) From the following structure <account>....some elements....<balance>200.00$</balance>....some elements....</account>. The elements content can be, and I said, can be, treated as one the elements properties. A property that could be either a value and/or a collection of elements. Off course this leads to a hierarchical data/"gizmo" structure and thus this construct could be perceived as a mini hierarchical data base by a procedural/functional programmer. We previously saw this type of programming in systems like autocad, MS office, Visio, Etc.. where function/procedure can manipulate a pre-built structure (ref: Programming by demonstration, The MIT Press (c) 1993 by Allen Cypher). (3) Principle of economy. Taking the path of least resistance or said differently the shortest path - i.e. a geodesic curve in the case of a curved space and a straight line in the case of a planar space. 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
|