Re: XSLT - Philosophical Musings

i guess future of XML/XSLT still clear in metaprogramming - you can
create branch of XML declarations about WHAT you need - then some
branches of XSLT to convert it into HOW to do it in 1-or-many
environments (LAMP, .NET, mobile aplications, hardware - arduino for
example)

2015-06-09 9:42 GMT+05:00 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