Ian Sparks <[EMAIL PROTECTED]> wrote: > > Mike Orr <[EMAIL PROTECTED]> wrote: > > > > XML is wonderful in theory, but in practice it takes something that > > should be simple and makes it ridiculously complicated.
Actually, depending on the nature of the data, the whole XML processing domain encompasses things which can be quite difficult. When I made a statement earlier about how XML is more than just an approach to representing data, but actually a "movement" to solving certain kinds of problems more effectively, I should have made the contentious-but-confident claim that there aren't that many tools or technologies around that deal with "deep", hierarchical data very effectively in the same way that relational databases provide robust support for tabular data. (Of course, SGML has been around for years, so I should qualify my claim by stating that there aren't that many "mainstream" tools or technologies...) [...] > > In the time it takes to learn DOM and XSLT, I could have my application > > already done. True, but it depends on a number of factors as to whether such technologies can be effective in any given situation. Getting back to the original topic, I can see that being able to treat user inputs from forms as XML results in a number of benefits that are hard to argue against for larger applications: validation of the user inputs, the ability to use standard APIs to access the data, the possibility to transform the data into user-readable output or into a format suitable for other application components or storage systems. Of course, in the case of a three field form, specifying lots of things in XML seems to be a disadvantage if one isn't familiar or comfortable with the technology, and perhaps it's easier in such cases to continue with programmatic validation of the inputs, programmatic access to (and storage of) the data, and use of more accessible templating systems. However, grow that form to 20 fields or more, make the nature of the data anything other than a flat tabular structure, and XML seems compelling if only because it's designed to address the problem area that you've just strolled into. >I understand the sentiment but the truth is that DOM, XSLT, XPath, SAX : all >these "ridiculously complicated" new languages represent real and worthwhile >additions to the programmers toolbox *because they are the same across >platforms and languages*. And I can imagine that environments may be developed around such technologies which pay less attention to the language being used, much like the way that Zope provides its own environment which doesn't necessarily demand Python expertise. >To take each example : > >DOM : A standard API for XML documents so much more than "just a way to get >a few tags out of your file" especially when combined with DTD's for >validating your input. Many people see XML as a nice way of "specifying my application's configuration" but then regard XML as overkill. However, the bad experience is as much caused by an uncompelling choice of domain in which to apply the technologies as it is the partial embrace of those technologies in that domain. >XSLT : No offence to the cheetah guys but XSLT is more, so much more (This >doesn't mean that Cheetah isn't the best choice for any given application). The problem with XSLT is that it doesn't have the transparency that other "presentation technologies" have, largely because it's more than a templating solution, and I believe that there are a large number of domains where templating solutions are not only more appropriate - they're actually preferable to the complexity that XSLT introduces. >XPath : As "ridiculously complicated" and as useful as SQL for RDBMS's. I can understand the sentiment that in learning XPath, you feel like you're learning yet more new (but somewhat familiar) syntax for things that you could have expressed in a language you already know. Amusingly, my experience of XSLT with substantial XPath tomfoolery led me to believe that combining the two technologies can make them seem weaker (or more obscure) in comparison to the other XML technologies used through existing programming languages. Bill Eldridge <[EMAIL PROTECTED]> wrote: > >Well, just try adding validation to your project and you find >yourself adding 2 or 3 more kits (and having to learn them, >of course). Still makes me wonder how people get away without >validation, but someone at 4Suite assures me it's relatively >rare for people to validate. Well, I've seen environments where validation is important, and I can imagine that in a business-to-business context it's essential. In such environments, programs aren't casually dealing with "stuff they've found on the Web which might be interesting" - the data coming in has to be right, otherwise it's sent straight back for corrections and the transaction doesn't take place. Paul _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
