Re: [xml-dev] SGML complexity

[<juanrgonzaleza@canonicalscience.com>]

Alexander Johannesen said:
>> > Oh yes, by a large degree. XSLT as a language is substantionally
>> smaller, smarter, and more dedicated.
>
> On 9/7/06, juanrgonzaleza@canonicalscience.com
>> Other strongly disagree with you. Any statistics at hand?
>
> Huh? people disagree that it is smaller? The XSLT (1.0) standard is less
> than 120 pages complete, while PHP and JavaScript both reside in several
> hundreds, because, you know, they can do more, and, you know, XSLT can
> do less, for very good reasons.

<div xml:lang="en">
I thought you were refering to size of code generated rather than the
specification. However, now you introduce an interesting point. Take the
specification for language A being 100 pages in size and 85 for the
language B. Now i translate both to Spanish and the specifications gots
120 pages for language A and 135 for B. What is supposed this to mean?
</div>

<div xml:lang="sp">
Creí que te estabas refiriendo al tamaño del código generado y no a la
specificación. No obstante, has introducido ahora un tema interesante.
Imagina que las specificaciones ocupan 100 páginas para el lenguaje A y 85
para el lenguaje B. Ahora traduzco ambas al español y el tamaño de las
specificaciones cambia a 120 páginas para el lenguaje A y a 135 para el B.
¿Qué se supone que esto significa?
</div>

<div xml:lang="gl">
Pensei que te referías ó tamaño do código xerado e non á especificación.
Nembargantes, introduciches agora un tema interesante. Imaxina que as
especificacións ocupan 100 páxinas para a linguaxe A e 85 para a linguaxe
B. Agora traduzo ambas ó español e o tamaño das especificacións cambia a
120 páxinas para a linguaxe A e 135 para a B. Que se supón que isto
significa?
</div>

> Which is the next point ; more
> dedicated. People disagree with that? It's about XML. Not about
> networks, or hash-codes, security, business logic, data layer access.
> it's about taking XML as input, and convert it to XML, HTML or text.
> That's it.

And some people continue disagreing! Since only a subset of XML files can
be easily transformed via XSLT. Far from problem with dinamical
transformations (stuff you can do with EcmaScript-JS but not with XSLT)
next page

[http://www.xml.com/lpt/a/831]

contains interesting thoughts:

<blockquote>
Try not to take a flat XML and convert it into very deeply nested
structures...Similarly it is hard to generate nested lists.
</blockquote>

Whereas transforming this XML

<paragraph>This is <highlight level="1">very</highlight>
important</paragraph>

to this one

<p>This is <em>very</em> important</p>

is trivial (but verbose)

transforming this

<math code="LaTeX">x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}</math>

to this

<math>
  <mi>x</mi>
  <mo>=</mo>
  <mfrac>
    <mrow>
      <mrow>
        <mo>-</mo>
        <mi>b</mi>
      </mrow>
      <mo>&PlusMinus;</mo>
      <msqrt>
        <msup>
          <mi>b</mi>
          <mn>2</mn>
        </msup>
        <mo>-</mo>
        <mrow>
          <mn>4</mn>
          <mo>&InvisibleTimes;</mo>
          <mi>a</mi>
          <mo>&InvisibleTimes;</mo>
          <mi>c</mi>
        </mrow>
      </msqrt>
    </mrow>
    <mrow>
      <mn>2</mn>
      <mo>&InvisibleTimes;</mo>
      <mi>a</mi>
    </mrow>
  </mfrac>
</math>

can be a nightmare in XSLT 1 (specially when compared with JS-DOM or PHP
methods). I do not know of XSLT 2 new capabilities but Mike here could say
us something.

> Smarter? I think you need to judge smartness on what it does and not how
> it looks. So does PHP convert XML smarter? Does JavaScript convert XML
> smarter? They both can do it, but not smarter (and smarter is more
> efficent, better thought out, more flexible, cleaner, no mixed
> development environments, etc)

Similar thougths than above. Sometimes XSLT is better sometimes it is not.
The hype about XSLT _is_ cool _and_ a powerful way to transform XML docs
has many 'iffs' between.

Not sure if XSLT is more efficient than EcmaScript approaches. Direct
manipulation via DOM is slow but inner methods are very fast and reason
that last Firefox introduce a propietary XML inner method if i remember
now correctly.

>> You see XSLT more focused to 'machine'. Whereas PHP opens the doors of
>> creativity and this appears to be a serious trouble for you.
>
> Really? I'm a serious professional PHP developer of many years, you
> know. I know my PHP pretty darn well, but I know when to use what tool
> and what they are good for.
>
>> > XSLT is for
>> > transformation, not programming, and hence don't need all that
>> complexity.
>>
>> XSLT can be considered a programming language in all right:
>
> You can do the same with Logo. However, speaking of it as such in
> professional circles will have you laughed at, so it doesn't
> necessarily mean you should do so. Just because you *can* do
> programming with XSLT doesn't mean you *should*. it is *not* a
> programming language; it's a transformation language. Please read the
> standard. It says so at the top of it.

Ok, but still your initial <q>XSLT is for transformation, not
programming</q> and your new <q>it is *not* a programming language; it's a
transformation language</q> both conflict with next

<blockquote>
XSLT can be considered a programming language in all right
</blockquote>

and

<blockquote>
It is a complete programming language that is capable of transforming the
source data in arbitrary ways for presentation, or indeed for input to
another application.
</blockquote>

This has been said by current XSLT editor here

[http://www-128.ibm.com/developerworks/library/x-xslt/]

Therefore with whom would i agree with he claiming that XSLT is PL or with
you claiming is *not* a PL.

>> > This is silly. Why didn't you search for "XSLT rocks" instead? --
>> http://www.43things.com/entries/view/417053
>> > -- http://norman.rasmussen.co.za/45/xslt-transformations/
>>
>> What is silly?
>
> Throwing around random quotes from links found on the internet as
> evidence of quality. My "rocks" can match your "sucks", so it's
> pointless.

Then you would re-read this thread because i explicitely said that larger
popularity do not imply better quality.

>> That you erased the links contradicing you? That Michael
>> Kay said that "That means there is a steep learning curve and often a
>> lot of frustration"?
>
> The steep learning curve is there *because* people treat XSLT as
> something it isn't. Which is at the heart of this very thread.

Maybe it <q>isn't</q> a programming language as you claim and other refute?

What people consider that XSLT is a language for *any* transformation but
it <q>isn't</q> becase limited to certain -broad but incomplete- class of
transformations?

I do not know many of XQuery, but it appears that is able to do tasks
cannot be done via XSLT. At least this is said in the Wiki

[http://en.wikipedia.org/wiki/Xquery#XQuery_and_XSLT_compared]

>> > Obviously not all agree it sucks. I can also provide you with quotes
>> that says that once you do what you're supposed to do instead of
>> doing what you think you should do, XSLT is *the* XML tools of
>> choice.
>>
>> Many other strongly disagree!
>
> People disagree that I can provide quotes to a contrary view? huh?
>
>> I already cited a bit.
>
> Well, screw the citations, and listen to people who use it and
> understand it, then. The discussion should revolve around judging XSLT
> on what it is designed to do, and not whether people understand that or
> not.

But here we can see you claiming that XSLT is not a PL and one of XSLT
masters claiming the contrary.

> I don't go around critisising basso continuo notation out of hand,
> because I simply do not understand it fully, even though I may have read
> heaps about it, heard lots of it and even written about it myself; it
> may even be hard to understand due to my *own* faults
> (intelligence, skills, knowledge, drive, etc), not the thing itself
> (which, in the case of basso coninuo notation is brilliant; the worlds
> professionals played baroque music for over 200 years thinking they had
> it, when in fact they didn't).
>
>> Now i can introduce
>> "Transcending the limits of DOM, SAX, and XSLT" article
>
> They critisise XSLT's verboseness by introducing a HaXml that's even
> more verbose. I can't take this stuff seriously, sorry.

Well, main emphasis of the author is in certain class of manipuations
cannot be done with XSLT (verbosity aside):

<blockquote>
The XSLT in Listing 2 seems simple and direct: you just create a template
to describe how you would like each element formatted. What could be
easier? The problem comes as soon as you want to filter or compute
something for the output -- something that is not included in the few
comparisons available to XSLT. For example, maybe you want (in a
numerological spirit) to display only the even-numbered hexagrams, or only
the prime ones. With XSLT, you are out of luck for something this simple.

At this point, you might turn to DOM or SAX for the task.
</blockquote>

>> Aside from the somewhat annoying verboseness of XSLT, it is limited in
>> its expressiveness -- the things you can say are expressed rather
>> clearly (and functionally, not procedurally), but you quickly bump up
>> against all the things that you simply cannot say in XSLT.
>> </blockquote>
>
> XSLT is *not* verbose ; XML is.

This is like saying XML is *not* verbose only its syntax is!

> I wish people would get their head
> around that. And the quote "limited in its expressiveness" is complete
> bollocks and stinks of an agenda of the author.

Ad hominen attacks so early?

> Sorry, I cannot take
> this stuff seriously until they explain *what* expressiveness they feel
> is lacking, because from looking at the examples I reckon those feelings
> portrayed comes from their lack of understanding XSLT. Here's a quoted
> hint from that article ;
>
>>>> XSLT is a special-purpose functional programming language that
> allows you to
>>>> specify transformations of XML documents into other things
>
> Which is bollocks and a testament to the authors knowledge of the
> subject matter.

Whow!!

From the ABSTRACT of the XSLT 1.0 spec [http://www.w3.org/TR/xslt]:

<blockquote>
This specification defines the syntax and semantics of XSLT, which is a
language for transforming XML documents into other XML documents.
</blockquote>

Is the XSLT spec officially stating that HTML docs *are* XML docs? I
really am missing something today.

> ...
>
>> I would are surprised if you are able to reproduce ASCIIMATH using
>> XSLT for instance.
>
> That just proves you either a) don't understand XSLT, or b) you have
> chosen the wrong tool for the job.

I doubt since after some earlier tests i decided that was *not* the
correct tool; but that did happen many time ago...

Let me remark that the need for a full-transformation language was
XML-based is still open.

> You cannot say XSLT is bad because it
> doesn't do X unless it's stated somewhere that XSLT does X good.

i am doing a full review of XSLt capabilities then i agree. Note that i
said in this list that XSLT has *both* strenghts and weakness. It is
atonishing that often your reply is just a <q>XSLT rocks</q>.

> XSLT is
> *not* a programming language, period.

Except by your continued ignoring that the own XSLT editor disagrees with
you.

> That some people abuse it as such
> is not a testament to the goodness of XSLT, only to the stupidity of
> some people.
>
>
> Alex
> --
> "Ultimately, all things are known because you want to believe you know."
>                                                          - Frank Herbert
> __ http://shelter.nu/ __________________________________________________

Since your replies are so polarized to heavy criticism (and ad homined
attacks) to something/someone contradicting you, let me think twice before
reply to you in a future.


Juan R.

Center for CANONICAL |SCIENCE)