Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SGML complexity
 juanrgonzaleza@c... 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@c... >> >>>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 
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
