RE: problem with xsl:copy-of and counting lines

Nicely put, Wendell.  This helps me as a non-programmer. :)

Steve

--
Steve Janoff
Information Manager, Specialty Engineering
General Atomics Aeronautical Systems, Inc.
Tel. (858) 909-5164
Fax (858) 455-4668
Steven.Janoff@xxxxxxx


-----Original Message-----
From: Wendell Piez [mailto:wapiez@xxxxxxxxxxxxxxxx]
Sent: Wednesday, June 20, 2007 8:21 AM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re:  problem with xsl:copy-of and counting lines

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 source object is an printed broschure which was generated in
>InDesign. I want to create a more automated possibility for ceating the

>print data. Thats why I "try" to learn XSL(T) because the source data
>comes from a database as xml files.
>
>The main problem is that the document has a more or less complex
structure.
>For example every page has a different number of lines. If there is a
>less number of lines than the maximum number of lines on a page the
>rest of the page will be filled by announcements or sth else from a
>pool of grafics.
>
>My suggestion was: page height minus the lines of a certain group of
>elements so that I can see if there is enough space for an announcement

>or not.
>
>At the beginning of the project I was very enthusiastic but now I
>realise how much programmers know how is behind the "small" broschure.
>And I am not a real programmer. My first contact with programming.

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
======================================================================