|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SGML complexity
 On 9/8/06, juanrgonzaleza@c... > 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/ __________________________________________________ 
[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! 
Cast Your Vote
We need your help – Vote for DataDirect XML Products!
Winners and finalists announced at SOA World Conference in November. 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
|
|||||||||
|
|
| Stylus Studio® Developer Network | Contact Us | Email this page |
| PRODUCTS | TRY | BUY | LEARN | SUPPORT | COMPANY |
 Cart
|
