|
I'll take your dollar and double-down. " The problem is that developers faced with XML tend to learn only one toolkit... but it tends to be the most complicated one." Given no assumptions about the problem ;) What IS the easiest toolkit that you would suggest specifically not knowing the problem ? (and define "simple" and "complex" from a novice perspective). Now suppose you (behind Door A) DO know the problem but are somewhat ignorant about XML and need to pick a tool ... Some toolkits may be *too simple* (say dont support namespaces well enough ...) So you at least have to know about namespaces and which tools support those, and what they are enough to determine if your XML needs that. What about data
size ? How big is your XML ? How much memory is required for ToolX to handle your largest document ? How about lots of documents ? Can you load them all at once ? or do you have to handle them sequentially ? Do you need streaming ? Could you define in one sentance
what Streaming is? Could you identify which tools and what subsets of features support Streaming? Validation ? Is that needed ? Does ToolX handle validation ? DTD ? XSD ? Which version ? Does your app language have direct XML support ? on the details of your project ? What about the next project ? Do you want to invest in learning X knowing it might not solve Y later ? How about transformation ... do you need it ? Do you know what it means and problems it solves (and generates)? Is it fast enough for you ? Do you want to learn XSLT sufficiently to determine if you could have done it some other way ? Which version of XSLT ? Does your system have it installed ? How about a third party version ? Which one ? is it free or costly ? Is the cost worth it ? If so can you justify it with sufficient detail to your manager to get funding for it ? Will the free version be feature-ful enough that you could get by with it even if its not ideal ? How do you know ?
I argue you *do* actually need to know quite a bit of specialist knowledge of XML to answer the above, and if you dont answer the above you are prety much guaranteed to pick an inappropriate tool.
Now knowing quite a lot about XML I happen to easily come to the answer for a given case, usually but sometimes I stumble. ... but knowing many quite smart
programmers who are nonetheless XML ignorant, they *don't even know what questions to ask* ....
---------------------------------------- David A. Lee From: Uche Ogbuji [mailto:uche@ogbuji.net]
On Mon, Jun 3, 2013 at 3:30 PM, David Lee <dlee@calldei.com> wrote:
People don't need to be an expert at everything. The era from von Neumann through David Bentley is well over, and I don't think anyone imagines it's not.
This is where I disagree. I do think you need to be an expert at XML to do certain things with certain tools. But I don't believe the simple data extract mentioned here is one of those things. The problem is
that the tools which are always the first on the marquee are rarely fit for purpose for any task, and XML does too poor a job at showing the desperate hacker the way to accomplish basic tasks. In other words, the problem is one not of expectations but rather education.
Only if you truly expect in your job to come across the full profile of problems that require this long list. I think very few developers ever do, and so for most I do think just learning one toolkit, and preferably
the easiest one, is fine. The problem is that developers faced with XML tend to learn only one toolkit...but it tends to be the most complicated one. Again it's only our own fault. -- |