Re: [xml-dev] SGML complexity

["Alexander Johannesen" <alexander.johannesen@gmail.com>]

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.

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

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

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

> Whereas transforming [..] "<paragraph>This is <highlight level="1">very</highlight>
> important</paragraph>" to [...] "<p>This is <em>very</em> important</p>" is trivial
> (but verbose)

Ok, mister Smarty-pants, show me how XSLT is so much more verbose
than, say, Java, using the same simple example as above.

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

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

I'm afraid *any* tool you choose has "if's" attached. All I *am*
saying is that you need to choose XSLT for the right reasons. Not sure
where the discrapency in this dicussion thus have come from.

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

...

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

> <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.
Yes, programming stuff is bolted on, and yes you *can* do shitloads of
crazy stuff with XSLT; I've spent many hours of fun programming in
XSLT to see what I can squeeze out of it, all for fun. But would I do
it if my life depended on it? Hell no. Again, just because you *can*
doesn't mean you *should*. You *can* create an accounting package in
Logo, but it doesn't mean you should.

...

> I do not know many of XQuery, but it appears that is able to do tasks
> cannot be done via XSLT.

Not "cannot do", but "tricky to do", although some XSLT processors
have XQuery support built in. I've create a full Topic Maps query
language in XSLT, which many would say is completely off the scale in
terms of insanity! You *can* do it. But that doesn't mean *should".
(Even though I did, mostly because it was a tremendously fun excercise
...)

...

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

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

I believe this is introducing strawmen so you can quickly burn them
and win the argument. For example, they could be after something
completely different which is totally easy. Who knows.

...

> > XSLT is *not* verbose ; XML is.
>
> This is like saying XML is *not* verbose only its syntax is!

You're insane! :) You're pretty stuck on hating XSLT, aren't you? XSLT
was designed with XML at the core. You can whinge about that all you
like, but there are certain qualities and limitations that comes with
that design decision. There's been good artists who's draw beautiful
pictures using rather revolting base materials.

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

Huh? Do you know what that means? Smelling out someones agenda is not
the same as saying the person stinks. If I say that X is limitless in
its expressiveness without actually telling you what "expressiveness"
mean but instead provide an alternative that is so much better without
saying why it is *better*, doesn't that trigger some warning signals
with you?

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

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

Huh? XSLT was designed with XML in mind. Do you mean a transformation
language that's general enough to swallow it all? XSLT has never laid
claim to such.

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

Have I?

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

...

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

Polarized and ad hominem? I think that deserves some proof. And
please, think all you like, not once or twice, but lots. I approve of
thinking. In fact, I encourage it.


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