[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SGML complexity
On 9/12/06, juanrgonzaleza@c... > 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 [expletive deleted] 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/ __________________________________________________
[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
|