Re: insanse discussion with alex Was: [xml-dev] SGML complexity

[<juanrgonzaleza@canonicalscience.com>]

Alexander Johannesen said:
> On 9/12/06, juanrgonzaleza@canonicalscience.com
>> One of design principles of XML is that terseness is of no importance.
>> Then we _cannot_ critize XML because being very verbose often.
>> However, we _can_ critize the application of XML in situations where
>> verbosity is a point and alternative approaches are better.
>
> Huh? We cannot criticise XML for the shape of it, only applications
> shape as a result of it?

We cannot wait X verifies Y requirement, when X was not designed for that,
but if Y is of importance on your own field of interest then you can
critize any approach based in X capabilites.

>> Size matters even if there exists a clear tendency to minimize this
>> fact from part of the XML comunity.
>
> If size is a problem for you, use something else.

It is just people is doing. I simply remarked that often XML folks
minimize the problem of oversize with (in)famous quote "XML compressed
very well". In my opinion that quote just _recognizes_ the existence of a
problem in many today applications of XML.

>> Two links:
>
> Do you have anything substantial to say except links to what others are
> saying?

>> Neil Soiffer claims Mathematica file can be 11 times larger than in
>> p-MathML.
>
> These figures are only important when you haven't got the smarts to put
> those files in a processing workflow where you convert them to what you
> prefer them to be.

Only? Not true!

> Size only matter when you work directly on them. Are
> they to big? Convert them to something else! It's not that hard to do;

Not true was not hard, since there is an important time-delay when
transforming big files and maybe memory limits.

>> [...] An oversize of 15x is not an option, sorry.
>
> Then go and use something else.

But missing the context of: please do not claim XML hype of terseness is
of no importance with current HD costs any more.

>> > Um, but you see, the part where you're failing miserably is that the
>> part of your example that you claim is hard to do in XSLT is the
>> part that *isn't* XML.
>>
>> Then SVG is not XML according to you ;-)
>
> Let me repeat myself, and I beg you to read it as it stands ;
>
>   "the part of your example that you claim is hard to do in XSLT is
> the part that *isn't* XML."
>
> *The part* of your example. The *part*. And that part *isn't* XML
> structured, it is a text string which needs to be interpreted
> differently to XML (you know what ML stands for, right?). XSLT is good
> for XML. Not so much for text, unless you do XSLT2 where it's a bit
> better.

Therefore, _according to you_ SVG is NOT XML. I think that you fail to
understand that part becomes to the whole and if that part is not XML then
the whole cannot be XML. This is elementary ensemble theory.

Your claim that a XML doc is composed of XML parts and non-XML parts is a
bit surprising at least, is not?

>> And then, according to you,
>> <math code="LaTeX">x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}</math> is
>> not XML.
>
> You're either completely insane, or don't read me well, so let me feed
> this with a bigger spoon; the part that *is* a problem to parse in XSLT
> is this one; "x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}" and that part is
> tricky because it - in isolation! - is not XML, but a text string. XSLT
> was not designed with all the text string whistles and bells you
> require, hence XSLT is a poor choice of tool for you (unless you can fix
> it into XSLT2, regexp and tokenisation).

It is very simple. Next is a XML doc

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<math code="LaTeX">x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}</math>

And _any_ on it is XML:

[http://www.w3.org/TR/REC-xml/#sec-element-content]

Or in plain words:

<blockquote>
An XML element is everything from (including) the element's start tag to
(including) the element's end tag.
</blockquote>

[http://www.w3schools.com/xml/xml_elements.asp]

And when transforming the _pure_ XML element

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

to the _pure_ XML element

<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 a XML doc into another XML doc. If i am doing a XML
transformation and XSLT is for that, what is then the problem?

Simply that XSLT was designed with certain class of transformations in
mind -historically XSLT was designed for the class of transformations
needed in XSL-FO even if after was splinted and can be used in an
independent way-.

You have stuff in XSLT/XPath for transforming PI nodes, attribute nodes,
element nodes, comment nodes, AND text nodes. Yes, text nodes also!

In fact, XPath includes stuff

[http://www.w3.org/TR/xpath#section-Text-Nodes]

for transforming next XML element

<author>Johannesen, Alexander</author>

to XML element (note the extra reordering)

<author>
 <first_name>Alexander</first_name>
 <last_name>Johannesen</last_name>
</author>

Do you know? That is a XML transformation can be done via XSLT. Nothing
absolutely nothing in the source

<author>Johannesen, Alexander</author>

is "non-XML" as you claim again and again...

Next link contains a XSLT template from Jeni Tennison implementing a basic
tokenizer in XSLT 1 for arbitrary delimiters

[http://www.exslt.org/str/functions/tokenize/str.tokenize.template.xsl]

In fact transformations of this class are very usual. Look at the XSLT

<!-- xq324.xsl: converts xq323.xml to xq325.xml -->

sited in

[http://www.xml.com/pub/a/2002/05/01/xslt-string.html]

transforming the XML element

<binCode>12D-1</binCode>

to the XML element

<productLocation>
 <row>12</row>
 <shelf>D</shelf>
 <prodNum>1</prodNum>
</productLocation>


The *problem* with my initial XML doc --> XML doc transformation, is that
is too complex transformation for XSLT, not that was a transformation of
"non-XML" stuff as you incorrectly pointed many times.

>
>> Last EcmaScript was designed with XML in mind, do you know?
>
> Last EcmaScript was not; the E4X extension was ; "E4X : Standard
> defines the syntax and semantics of ECMAScript for XML (E4X), a set of
> programming language extensions adding native XML support to
> ECMAScript." it's a bolt-on.

Whow! but still "Last EcmaScript [Specification] was designed with XML in
mind, do you know?" hold.

>> I think that both Mike and me said in this thread that XSLT becomes to
>> the class of special-purpose programming languages.
>
> I think you're insane; in defining XSLT being a sub-class, you still
> insist on comparing it to its super-class.

Only in your mind is the mixing of classes ;-) I simply said that XSLT is
a programming language. XSLT is a special-purpose programming language,
therefore is a programming language. I never said that XSLT was Java or C,
but the three _are_ programming languages. This is simple ensemble theory.

>> I have no problems with different views on same topics. The existence
>> of differnt views is one quality of knowledge adding richness. I are
>> tired is of your pontification tone (periods included ;-). When you
>> claim that
>>
>> >> > XSLT is
>> >> > *not* a programming language, period.
>>
>> We would reply AMEN!
>
> You claim XSLT is a specialised functional programming language, yet you
> say amen to me saying it is *not* a programming language?

Read again!

>
> Alex
> --
> "Ultimately, all things are known because you want to believe you know."
>                                                          - Frank Herbert
> __ http://shelter.nu/ __________________________________________________

Juan R.

Center for CANONICAL |SCIENCE)