Cart
[Home] [By Thread] [By Date] [Recent Entries]
ricko@a... (Rick Jelliffe) writes: >On the other hand, without certification schemes to provide a basic QA >that your human is up-to-speed, it is difficult to imagine that the >current generation of XML tools can get much deployment -- the 2003 >generation (Office 11 etc) will have the same problem that the >products of the previous product cycle (the B2B bubble) had: not >enough skills to take maximum advantage of it. Computing professionals seem to regard HR as horrible but inevitable, something that can't be fixed, which I think is a mistake. I tend to regard research and conversations as a better approach to QA. Not that my record is perfect - my authors have on occasion wandered off or proven not to know their subject in enough depth. Still, reliance on certification strikes me as a sign that people simply can't be bothered to actually figure out what's in a potential employee's head. >Certification by reliable bodies is the only way an exploding >technology can be taken advantage of, for many companies. Large-scale use of certification (and learning on the job) may in part explain why so much of the XML work out there is technically acceptable (well-formed) but lacks any deep thought about its reusability. >I used to >teach SGML courses and then XML courses, and I found the XML students >had very different mental furniture to the SGML students, which I >think Simon also points out in this thread. I think the largest differences is a simple cultural one. As I've gone back through SGML archives, it seems pretty plain that the SGML community encouraged developers to think about why they were doing something. To some extent, that was because choosing which SGML features you used was an important task, but it probably also have had to do with who came into SGML, the projects they worked on, and the timeframes for those projects. Outside of xml-dev, roughly 90% of the people I deal with have no interest in which parts of XML might be useful or how best to structure their documents. They want to throw existing structures into XML's magical interop soup or they want to latch on to a specification that someone else developed. I suspect this may account for the large numbers of people who want books on programming for (around?) XML but aren't interested in books that explain XML itself. Many people also seem to think that XML should take about an hour to learn and get be bothered to explore in greater depth. Oddly, these are often people (like those in OOP and RDBMS work) who come to XML already having climbed a few steep learning curves. >I have found that people >who learn XML on-the-job often have very great deficiencies: I think >the areas of namespaces and encodings are the two that most commonly >seem to stump people (or where they blaze ahead wrongly). That concurs with my experience on the specifics. More generally, data modeling is hard work, and learning to model complex data structures with XML takes a while. >I guess what would be great would be a WebStandards project to certify >the certificates! I suspect more emphasis on educating people in the first place would be a more productive use of time than working on certification of any form. -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com -- http://monasticxml.org
|
