Re: [xml-dev] SGML complexity

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

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?

> 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. What exactly is your
problem? If you don't like X, don't use X. Whinging about the
verboseness of XML is not going to make that go away. Go over there
and talk to those binary XML folks, because that's what you're after.

> 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. 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; lots of people do it all the time. XML is an exchange
format, not necesarily a processing format.

> [...] An oversize of 15x is not an option, sorry.

Then go and use something else.

...
> For instance "easy" is used twice in
...
> and is also used several times here
...
> and here
...

Look, I too know the trick of Googling "xslt easy", but it doesn't
prove anything; they are quotes take drastically out of *this*
conversations context. It *is* easy to do XSLT. And hard. It depends
on what you're trying to do. The exact same thing can be said for
pretty much anything on this planet! I just don't grok what you're on
about. Which problem are you trying to fix?

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

Yes, you can throw in the "contrary argument" (no matter how
underspecified it might be)  at any time to debunk any argument I
provide. And you know what that amounts to? Nothing. Absolutely
nothing.

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

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

We wrap content in XML all the time; that's our bread and butter. Some
times our content is marked up in XML (semantic XHTML, for example)
and XSLT *thrives* in transforming it, because, it's an application of
XML. All is good. But other times it is text or something else that
XSLT doesn't really understand the structure of, and so, if this is
your primary task in transformations, then XSLT is a poor choice for
you. For *you*. Not for the world at large, but for you, because it
didn't fit your task.

When XSLT was designed, the problem was XML and how to transform it
from X to Y, so it was designed to deal with XML well. Wrapped in XML
there is bits of text, but that's a secondary item to the primary.
When you judge XSLT, shouldn't you judge it for what it was designed
to do (XML), and not what's a secondary thing (text parsing)?
Seriously?

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

Huh? Now you're being plain ridiculous. How on earth do you get from
"use XSLT for XML structures, and if you've got shitloads of text
parsing, use something else" to "you can't use XSLT for _any_ XML"?
Where does your brain make this quantum leap? It boggles my mind. I
use XSLT for lots of transformations with *great* success. Am I
missing something?

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

> > Yeah, someone says it can be considered as such. I don't.
>
> "Someone says"?

yes. Someone says. Lots of people says. And then, lots of other people
says the contrary. :( I'm so sick of this argument.

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

> I thought that any
> current programmer would understand a class is, sorry if i was too far
> here...

Wow! You complain about ad hominem a lot, don't you, and then it turns
out you are indeed eating your own dogfood, as it may be. Practice
what you preach, not what you do, eh? Just because *you* see it as a
sub-class and want to compare it on equal terms as a super-class
doesn't mean the rest of the world follows your notion, nor should you
assume so in argument.

...

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

I don't even understand what you're saying here. There's *lots* of
things I don't carefully say at any given time on any given topic,
because, you know, it just might be completely irellevant! How the
hell am I to preempt what your brain might be thinking?

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

The former is yours (and Michaels, depending on context and
willingness), the latter is the designers of XSLT. In judging what
XSLT then is about I'll go with ... hmmmm, I don't know, difficult
choice, I don't know .... oh, ok, I'll go with the designers of the
language. Do you see the difference here? One is opinion, the other is
documented "fact". To further this, what is the difference between ;

 1. You recognising XSLT being a functional programming language
 2. You recognising XSLT being a piece of shit

Nothing; they are both your opinions, and I disagree with you on both
accounts. Others may have other opinions on it, as we have seen, some
share your point, others don't. So in trying to get to the crux of the
matter, we can look to its design. And by luck XSLT is embedded in a
standard so we can go there and check. And golly, did you know that
neither the word "functional" nor "programming" is to be found
*anywhere* in the specification, not once? Does that indicate
something? Perhaps it indicates that its purpose may not have been
functional nor programmatical, that these are opinions based on
observation, but was nowhere in the mind of those who designed the
darn thing?

...

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

You're absolutely insane, and I give up. Go on, hate XSLT all you
like, and *please* use something different. You are right; XSLT can't
be used for anything; there is nothing beautiful about it; it cannot
solve serious and complex things; it was designed for programming on
par with Java and should be judged as such.

I beg you; please never touch XSLT again. You might get my disease.


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