Re: [xml-dev] SGML complexity

[James Fuller <jim.fuller@ruminate.co.uk>]

juanrgonzaleza@canonicalscience.com wrote:
> Alexander Johannesen said:
> 
>>>>Oh yes, by a large degree. XSLT as a language is substantionally
>>>
>>>smaller, smarter, and more dedicated.
>>
>>On 9/7/06, juanrgonzaleza@canonicalscience.com
>>
>>>Other strongly disagree with you. Any statistics at hand?
>>
>>Huh? people disagree that it is smaller? The XSLT (1.0) standard is less
>>than 120 pages complete, while PHP and JavaScript both reside in several
>>hundreds, because, you know, they can do more, and, you know, XSLT can
>>do less, for very good reasons.
> 
> 
> <div xml:lang="en">
> I thought you were refering to size of code generated rather than the
> specification. However, now you introduce an interesting point. 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?
> </div>
> 
> <div xml:lang="sp">
> Creí que te estabas refiriendo al tamaño del código generado y no a la
> specificación. No obstante, has introducido ahora un tema interesante.
> Imagina que las specificaciones ocupan 100 páginas para el lenguaje A y 85
> para el lenguaje B. Ahora traduzco ambas al español y el tamaño de las
> specificaciones cambia a 120 páginas para el lenguaje A y a 135 para el B.
> ¿Qué se supone que esto significa?
> </div>
> 
> <div xml:lang="gl">
> Pensei que te referías ó tamaño do código xerado e non á especificación.
> Nembargantes, introduciches agora un tema interesante. Imaxina que as
> especificacións ocupan 100 páxinas para a linguaxe A e 85 para a linguaxe
> B. Agora traduzo ambas ó español e o tamaño das especificacións cambia a
> 120 páxinas para a linguaxe A e 135 para a B. Que se supón que isto
> significa?
> </div>
> 

this type of thinking reminds me of endless LOCC type debates with 
respect to programmer productivity.....whereas we know that well crafted 
(and endlessly refactored) efficient code should be less lines of code.

and at the other end of the scale, lets not forget about nature's 
millions of lines of messy DNA 'code', which is efficient in short and 
very long timescales.

terms like productivity are contextual (where precision and unambiguous 
meaning is required, I would suggest that we should now speak in German 
or Czech)

>>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. Far from problem with dinamical
> transformations (stuff you can do with EcmaScript-JS but not with XSLT)
> next page

'since only a subset of XML files can be easily transformed'????

untested: I should be able to able to apply an XSLT identity transform 
to anything easily.


> 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 dont think in terms of fashion with programming...I hate all computers 
and programming languages equally (at most times).

I grok XSLT, but I and most people on this list dont go on about it 
being cool. Actually, come to think of it the xslt list doesnt either 
(except for newbies).


> 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


when I transform XML it is for transformation, when I am programming 
with XLST its a programming language...splitting hairs here. Also past 
turing complete, etc....can anyone come up with rigorous definition of 
'programming language'?


> I doubt since after some earlier tests i decided that was *not* the
> correct tool; but that did happen many time ago...
> 
> Let me remark that the need for a full-transformation language was
> XML-based is still open.


I smell a product launch statement soon.....


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


why have you not brought such a debate to the XSLT List ?


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

I dont think that AL said are polarized.

I struggle to see the 'point of this thread'...but hell I feel that way 
with 80% of the traffic on this list because I dont know things well enough.

have a nice weekend.

cheers, Jim Fuller