[
Lists Home |
Date Index |
Thread Index
]
ricko@allette.com.au (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
|
