RE: [xml-dev] SGML complexity

[<juanrgonzaleza@canonicalscience.com>]

Michael Kay said:
>
>>
>> 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.
>
> The point I was making in that article, and it's still my view now, is
> that XSLT is a special-purpose programming language.

I agree! XSLT is declarative semifunctional (maybe functional) domain
specific programming language XML-based.

Now it is clear that "declarative semifunctional domain specific
programming language XML-based" is a _subclass_ of "programming language".
Therefore XSLT *is* a programing language like C, Java, Lua, Maple,
AppleScript...

Therefore, the claim that XSLT is not a programming language was plain wrong.

> It is programming,
> but it's specialized to the operations involved in transforming trees.
> That means, for example, that it wouldn't be my first choice of language
> for writing a parser (your maths example).

My double example was this XML

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

transformed to XHTML

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

and this XML

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

transforming to next XML

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

I am transforming trees in both cases of above; i am transforming a XML
doc in another XML doc. The problem with XSLT (at least 1.0 that i
studied) is that is not powerful enough for that kind of task. It was
designed for certain class of transformations in mind (basically those
required by Formating Objects).

You can manipulate the DOM via Javascript but is boring, complex, and
inefficient (XSLT approach is still poor). Probably E4X would be cheap but
is is only supported in Firefox browser today.

> I try to show in the article
> that it's capable of more than some people then imagined. These days I
> think its computational power is common knowledge. In a later paper I
> showed how XSLT 2.0 extends the scope of applicability by illustrating
> its use for up-conversion tasks, and I've also seen applications that
> stretch the boundaries in quite sensible ways to present numerical data
> in the form of SVG graphics.

It is interesting, it is to be remarked that SVG folks are introducing its
own binding language.

> It's always been a bit of an open question
> how far it was wise to go; for example there are certainly use cases
> where trigonometrical functions would be useful. In my view, we've got
> it roughly right in XSLT 2.0 - some people think the language has grown
> too big and some would have liked it to go further, for example to
> support higher order functions, but you can't expect to please everyone.
>
> Michael Kay
> http://www.saxonica.com/


Juan R.

Center for CANONICAL |SCIENCE)