Cart
[Home] [By Thread] [By Date] [Recent Entries]
Andreas,
At 08:07 AM 6/20/2007, you wrote: Okay, 10 steps back. At the moment I am working on my diploma for my degreed engineer. I wanted to do something with xml and some transformations. The trap you've fallen into is actually quite interesting -- you've underestimated not the difficulty of programming this, but the difficulty of the problem itself. That's a subtle distinction but an important one. How do we know how simple a problem is? From our attempts to specify it. In this case, you have part of a specification, but you have also probably discovered there's a big hole, namely in the definition of "line". Put simply, a "line" in the XML source (definition required!) may or may not -- but almost certainly, does not -- correspond to a "line" in the printed output (definition required again -- only to discover it needs a different definition). This particular gap is not one that is easily bridged. (Indeed, the kind of design you are doing, for a printed brochure, is known in the industry as "layout-driven", since it includes requirements for things like filling up available space with graphics and bits of available content -- and it presents a notoriously difficult set of problems for automation. Note that this same issue with what a "line" is does not arise when automating transformations for many other tasks, such as generating HTML from your XML, or even simple page layout without trying to fit graphics.) If a problem is simple, then specifying it is simple, and coding it is likewise simple. If a problem is complex, then specifying it is complex. But given a complete and correct specification, even a complex problem can be solved and even coded -- an experienced programmer may even solve and code it simply. Without a specification, however, designing a solution to a problem is impossible -- which leaves coding it right out. This is no less true when your problem specification and solution are only implicit in the code, and discovered through trial and error. Nevertheless, persist in your efforts and soon enough you learn is that specifying a problem, designing a solution to it, and coding it are three different things. Part of the experience that makes one a "programmer" (or makes one a valuable problem solver even if one never writes code at all) is to understand this, and to know, moreover, how to specify problems and design solutions without worrying about how that solution will be implemented in code. This is an extremely valuable lesson. Cheers, Wendell ====================================================================== Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
|
