Subject: Re: [xsl] XSLT - Philosophical Musings From: " Вячеслав Седов schematronic@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> Date: Mon, 15 Jun 2015 13:19:15 -0000 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] XSLT - Philosophical Musings, Hank Ratzesberger xm | Thread | [xsl] Can I see the main DOM from a, Craig Sampson craig. |
[xsl] Review - What's New in XSLT 3, Hank Ratzesberger xm | Date | [xsl] XPATH 1.0: Selecting an eleme, Malecki, Piotr piotr |
Month |