[xsl] XSLT - Philosophical Musings

["Hank Ratzesberger xml@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

Hello,

I started writing a review of Dimitre Novatchev's XSLT 3.0 training
course and began to digress about the philosophy of XML programming.
Well, I thought it better to put that in this post.

A very sharp colleague of mine only last week remarked "programming in
XML -- it's just not right."

I didn't have time to make the case then, so I'm making it to this
group, if any of you are interested.

XML transformation is scripted object programming and XML is an object
notation that is flexible enough to represent almost any kind of data.
There are even libraries to parse binary data into XML.

I think what my colleague was objecting to is "declarative"
programming, and I think we can have some sympathy, because the flow
control is not explicit. Regardless of the fact that XSLT programs are
often very robust and require fewer lines of code, they can be
difficult to read.

Also, I think because the implementations in browsers have been weak,
while JavaScript has become very versatile.

Finally, I would say that the "definition of data" hasn't changed in
thirty years.  When the word "database" is mentioned, it is almost
assumed we are discussing a SQL database. I had a small part of a ten
year geosciences research project that ten universities contributed
to.  I hoped they could reach agreement on ways to define and exchange
their data in schemas that represent a complete snapshot or
transaction or instance, with the metadata necessary to provide
complete provenance. In the end, they broke things down into tables
and probably at this time you can obtain JSON records and such. It is
easier to code than data, as it were.

Imperative languages exist so you can write declarative languages. The
reason I say this, without a lot of experience trying it myself, is
that when you have to require or explain or document a process, you
should be able to come up with a a limited set of rules that can be
generalized over the domain of your data or process.  If you can't do
this, then perhaps you are creating more exceptions than rules. Or
possibly, your logic is better expressed from the beginning in the
data rather than the code.

In my annual review, I jokingly explain how many hours I worked to
producer FEWER lines of code. Fortunately, my supervisors understand
that every line of code can have an error or create a new "corner
case" or something else that can go wrong.  But even this is a ratio
-- the number of lines divided by the number of times the lines are
executed. Even though XSLT implementations may require tens or
hundreds of thousands of lines of code, the fact that more than one
implementation is attempting to achieve the same, predictable, results
means that the code "sitting on top," the XSLT script is effectively
exercised more thoroughly.  You are coding on the shoulders of giants
and not in the trenches.

Dimitre said in an email 'I don't think many programmers know that
they can write programs this way' and I think that is the unfortunate
state.  Even some very astute colleagues will mention 'the steep
learning curve' but I believe the tools play a part in this. I think
there needs to be more code designers that attempt to hide the syntax.
I'm not sure this is a good example, but BPEL provides standard
graphical images (and hey, that worked for the Egyptians).

XML is readable, it just wasn't meant to be read. I think that any
code, in any language, that does anything significant, is equally
obfuscated, but perhaps programmers are just more comfortable locating
the decision points, or nowadays, the function that makes the decision
when invoked.

Cheers,
Hank


-- 
Hank Ratzesberger
XMLWerks.com