Re: [xml-dev] SGML complexity

[<juanrgonzaleza@canonicalscience.com>]

Alexander Johannesen said:
> On 9/8/06, juanrgonzaleza@canonicalscience.com
>> I thought you were refering to size of code generated rather than the
>> specification.
>
> XML is verbose. No one contests that. But please don't use that as a
> quality measure.

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.

Size matters even if there exists a clear tendency to minimize this fact
from part of the XML comunity. Two links:

[http://www.awprofessional.com/articles/article.asp?p=367637&seqNum=2&rl=1]

[http://blogs.msdn.com/brian_jones/archive/2006/05/16/599096.aspx]

Neil Soiffer claims Mathematica file can be 11 times larger than in
p-MathML. I have computed until 15 times when MathML encoding is compared
with a special representation i am working. 15 times larger is a lot of
and we can work with files larger that 131 Megabytes spreadsheets cited by
Brian Jones. In MP4 approaches, it is usual temporary files of 2 Gigas to
be stored in rapid memory (no HD!) during computation. But a Redfield
equation for a small physicochemical system needs of 7 gigas just to be
constructed. An oversize of 15x is not an option, sorry.

It is interesting that SVG WG introduced a non-XML parsing _because_
verbosity. The OpenMath approach defines a binary encoding alternative to
the XML one but i do not know about level of optimization.

>> 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?
>
> Why is it supposed to mean anything?

Ok, then it means nothing.

>> > 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.
>
> Huh? If it's XML, XSLT deals with it. You're bringing your personal
> opinions about what is "easily" to the table. Without a good
> definition of what that is, it becomes meaningless to say it's better or
> worse than the other.

It is true that "easily" is a subjective concept. Then the same criteria
applies to the XML community when it is said that transformations of XML
docs via XSLT are easy or when it is stated that XML is simplified SGML
where non-easy stuff was eliminated.

For instance "easy" is used twice in

[http://www.w3.org/XML/1999/XML-in-10-points.html]

and is also used several times here

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

"It means that it is easy to make an XSLT style sheet..."

and here

[http://www.xml.com/pub/a/2002/03/27/templatexslt.html]

The same criteria you require to me would be applied to other subjective
words also.

>> <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>
>
> It's a hint, not a rule. Take a flat XML format like XTM and
> converting that to a structurally deeper one is something that I would
> *recomend* and do myself on a daily basis. It's all about context.

Yes, context matter. But that 'hint' is reflecting something because in
the contrary case it would be not needed.

>> transforming this
>> <math code="LaTeX">x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}</math> to
>> this
> [big snip]
>> 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.
>
> 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 ;-)

And then, according to you,

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

is not XML.

> I don't think anyone would dispute that string
> handling is poor in XSLT, because, you know, it isn't what XSLT was
> designed to do well. Everything inside the <math> element is a text
> string. And yes, XSLT2 adds a bit more to text-parsing (regexp and
> tokenization, amongst other things), but I still recomend that people
> who's doing more text-parsing that XML has chosen the wrong tool.

Therefore XSLT is not the tool for _any_ XML transformation. It is just i
said at the very beggining. Sometimes it is the correct tool sometimes it
is not.

>> 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.
>
> Given that XSLT is specially designed with XML in mind while JS is not,
> I'd take my bets on XSLT where XML is concerned. Not sure you know about
> all the niceties you'll get for free if you follow some of the XML
> schema convetions, like indexed id[s] for example.

Last EcmaScript was designed with XML in mind, do you know?

> ...
>
>> 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>
>
> Yeah, someone says it can be considered as such. I don't.

"Someone says"?

Just another link:

[http://www.xml.com/pub/a/2002/03/27/templatexslt.html]

>> <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>
>
> Notice they still talk about transformation; it is the primary task.

I think that both Mike and me said in this thread that XSLT becomes to the
class of special-purpose programming languages.

About your emphasis on XML trasformations

XML(original) --> XML(final)

i only can say that other languages _are_ transformation languages in some
sense. Imperative languages transform program states

State(original) --> State(final).

Functional languages transform also

x --> y=f(x)

Etc.

> ...
>
>> But here we can see you claiming that XSLT is not a PL and one of XSLT
>> masters claiming the contrary.
>
> That's because you've chose to interpret that master in your own bias.
> Normally I think Michaels farts smell like roses, and I might even say
> that in this case we might disagree, but you see, in reality I don't
> think we do, and the emphasise here is "specialised"; XSLT is so
> specialised that trying to compare them to *generalist* languages is
> just plain wrong and stupid. Oranges and bananas, my friend; both
> fruits, but very different in taste *and* in whether you can use them to
> make jell-o / jelly or not

Since it was emphasized several times that XSLT is not a general-purpose
PL but a special-purpose PL, i see not your point. I thought that any
current programmer would understand a class is, sorry if i was too far
here...

>> 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 fail completely to understand you point here. My reaction was to "XSLT
> is a special-purpose functional programming language" which
> stands in stark contrast to "a
>> language for transforming XML documents". What is it that you're not
>> getting?

And you carefully say nothing about the stark contrast between the spec's
abstract and HTML or RTF outputs via XSLT.

Moreover i do not think that "XSLT is a special-purpose functional
programming language" was in stark contrast to "a language for
transforming XML documents". Both statements are closely related. A
function is a class of transformation, in fact a XSLT transformation is
just function of a special class where the argument is a XML fragment and
"programming language" is a class of language (or subclass of class
language if prefer).

>> > XSLT is
>> > *not* a programming language, period.
>>
>> Except by your continued ignoring that the own XSLT editor disagrees
>> with you.
>
> Disagreements you'll find between many otherwise equalminded people. It
> happens.

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!

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


Juan R.

Center for CANONICAL |SCIENCE)