Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: advocating XML
 ----- Original Message ----- From: Thomas B. Passin <tpassin@h...> > Well, I've also done the regex route, both with python and awk. In fact, in > this job, I got the form data into the database using python, no xslt or xml > involved. And I've generated enough html programmatically to know that I'd > rather use templates than functions. I agree ;-) Somehow ;-) Yes, it is better to generate html using templates! Both Python and Perl have dosen of solutions for that. As to XSLT *processing model* when rendering HTML ... It is fine for simple cases. In complex cases, XSLT turns to be a problem. > If I have a straight line-oriented job > I'll probably look at awk first, then python. So I do know what you're > talking about here. The problem is that for me it is now hard to tell if something is 'straight line-oriented' or not. I mean that many things could be turned into 'line-oriented'. Also, processing sections of lines with .section_begin content .section_end is not that hard in modern scripting languages ( Python and Perl are much better than awk .. ) > In fact, I'd bet that a lot of the people on this list have used their own > private text formats which they turn into xml using a script and some RE or > string processing. No doubt! My point is that I was also doing that for a while, then I saw XSLT and decided : "O! XSLT is so cool! I should replace my RE-based processing with XSLT-based processing". And then I tried hard. I've spend a lot of time doing that ( Ux was just an attempt to replace RE-based processing with XSLT-based processing ). After a long time of doing that, I realised ... It just [expletive deleted]. Really. What helped, was a quick look at Zope's horrible model. I just realized that this even 'horrible' model helps me *more* than 'accurate' and 'elegant' model of XSLT. > > Anyone who votes XSLT for programming language should take > > into account that xslt *silently* *ignores* almost any mistyping > > you have in Xpath expression. And there is no possible guard > > ( because building the guard kills the XSLT itself ;-) > > > > With regular expressions and accurate design of the 'line' > > you *do* have a guard ! > > I find regular expressions at least as difficult and error prone as xslt > expressions. I suppose it's a matter of practice and how your mind works. Nope. I disagree. With regular expressions you can test if re.match returns true and complain if it fails. And you do that in one if : else : statement ( it is simple and terse ). Try doing that in XSLT. No Way. re.match provides a guard, but Xpath has no guard. It just returns 'something empty'. I've seen a *lot* of situations when people are producing broken HTML with XSLT. For example, in a sense that some tags are 'kept', when they should be 'rendered'. Any XSLT transfromation that builds on well-known "identity transfromation" ( i.e. bypass everything that is not explicitely rendered ) is likely not to 'render' some tags. Silently. And such things are hard to capture even visually. > Either way, I have to do a LOT of testing. I usually find it's easier to > break a tricky RE than an xslt statement, but your mileage may vary, as > always. If you don't put else: branch after re.match - then yes. You may spend a lot of time testing. If your else: branch is complaning about 'broken RE' - you should be fine... if, of course, your delimiters are 'good'. I mean that to have efficient RE processing one should think about efficient delimiters and stuff before writing actual RE. The same 'look ahead' applies to XSLT. Some transfromations ( like grouping ) [expletive deleted] in XSLT, so the workaround is "change the schema". Really. I've been reading XSL list for a while and it was FAQ. Don't know if it is still FAQ. In fact Xpath and RE have many things in common, the only difference is that select="Xpath" has no reasonable guard. re.macth can return 'false'. > > 'there are better layers upon SAX' in Python, > > I'd say : "No. It is too complex. All you need is 3 lines of regexprs - get > real". > > Depends on the job. In this case, I'd need several scripts that play > together, and output some format, like HTML. I could easily have done it with > straight scripts. I tell you what, though. For a quick one-time thing, I'd > probably use a script and be done with it. But when I expect to do something > over and over with variations, I find I want templates and program/document > generators. ... both Templates and Generators *do*not* imply XSLT ( and XML ) > I look back at some jobs where I created a bunch of html by > scripting, and wish I had done them with templates instead. If you are using > xml, then xslt is a natural to use for templates, although you could of course > use something else. If you are using XML, XSLT is the *only*promoted*existing*scripting*tool*to*do*something*with*xml. Of course it is 'good'. It is 'the only one'. However, I now think that something like Matt's XPathScript may occasionaly replace XSLT ( when xml processing will be really used by more than 1000 geeks ;-) Xpath ( or XQL ) + Python or Perl scripting attached = should be best of both worlds, actually. > And some things are still done better with scripts. In the job I mentioned, I > used a mix. A simple Python/Perl library based on Text:Template + simplified Xpath + *really* small set of XSLT constructions - and you have the solution that should win *any* usecase over XSLT, because general-purpose scripting programming language will drive the show. Not so with Java, of course, but why should text processing be performed in low-level language? Even 30 years ago there was awk. I may write such a library occasionally in 2-3 weeks. But I don't think I will do that soon. Here is why: The problem is that nobody will use it like nobody now is using XSLT. I mean that I'm making money being a contractor in silicon valley. There is no reasonable contracts for XML / XSLT processing. Really. I've been looking for a year. When some contract has a word XSLT in it, it is usually talking about very funny rate. XSLT and XML are not considered to be a skill at all. I dont know why, but I think ... maybe ... people don't really use XML *that* much ( because if really use XML ... one may soon realize that scalable / efficient XML processing *is* a skill ). I mean they do use XML and I saw how they do that, but ... you know ... in one company they XML-ized one of their APIs and after one year they found it to be a disaster ... And I think they were right ...It was a disaster... The way they did it ... And the layer they've abused ... Really ... XML-izing is attractive, but it has too many catches. Remember Java? Remember these billions wasted into writing monsters in Java? Not that I have something against Java, but I started to like diversity ... and after the school of XSLT and SAX, I now write in RE as if I have XML - *that* really helps ;-) > So I actually agree with most of what you said, but I still come out with a > different conclusion. Well, go figure! Thanks for your thoughts. I think I should write the conclusions, because my lettres are messy, but so are my thoughts... Conclusion : 1. XML is fine when readability is important. 2. XML-ization of processing APIs and especially using XSLT for something other than rendering simple HTML pages is hard. And I doubt it makes sense in many cases. 3. The line between 'processing API' and 'XML that I export' is very hard to draw and I think that (3) is the biggest challenge of XML, because letting XML into places where there should be no XML is ... Not good ... I'm sorry for writing such a long letter, but I wish it explains my current position on XML and XSLT. I think both are good things but both are not a solution 'as-is'. And both are overhyped, I should say. When Simon said that "think if you will share the file" - I thought that what he says is very reasonable advantage for XML over CSV. When you added : "and you'd love some XML processing tools" - my reaction was : "Oh, no! It is not that simple with the tools!" Anyway, for some magical reason, most of developers whom I know are going over the same path with XSLT : "It is cool and simple - It is cool and complex - It is complex and it does not look cool for me". I have a feeling that the inventor of XSLT has reached stage three a bit earlier than the rest of us. ;-) 
|
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
|
|||||||||
