Hacker News new | past | comments | ask | show | jobs | submit login

One of funnest projects I worked on at Corel was called "Smart Graphics Studio" (I'm guessing most of the people who worked on it also read HN, so "Hi!"). It was an absolutely stupid idea: Some insane PGM read that XSLT could transform any XML into any other XML. Then they read that SVG was XML. They put 2 and 2 together and got a billion: You could draw a picture in SVG and then modify it intelligently (through XSLT) using some XML data set.

Of course the opposite is actually a brilliant idea (at least at a time when XML was still popular): Take an XML dataset and visualise it in SVG using XSLT transformations (well... yeah... doing it all in XSLT is still insane, but you get the idea).

Anyway, we built a very high performance SVG viewer (for the time, anyway) from scratch. We built an SVG/Javascript widget library. We built an incredibly impressive data manipulation library in XSLT (ok... yeah... insane).

Fun times. And all nearly 20 years ago. It really was ahead of its time. Of course the end finally had to come. The PGMs sold this thing to a certain aviation company with the promise that it would automatically build circuit diagrams from their XML chipset database (because.... XSLT!)

When Vector took over Corel, they very rightly dropped our division like a hot potato (we had something like 3 PGMs per developer). It was quite unfortunate because the developers and QA people I worked with there were some of the best I've every had the pleasure of working with. I've always waited for something to come of SVG and really wish we had been able to release something that wasn't crazy so that people could see what the potential was.

Edit: In my old age I'm losing track of time. It seems that Vector acquired Corel in 2003, so that's only 15 years ago :-)

It's such a shame that XSLT has such a poor image - v1.0 was troublesome for sure, but the modern language is remarkably flexible, expressive and elegant, as long as you leave your procedural baggage at the door.

It's not without its wobbly bits, but show me a language that isn't.

I should probably admit that I really like XSLT (perhaps I'm insane too), but it was really unsuited to the task we were using it for. I've since done quite a bit of XSLT and it's definitely the main tool I'd use if I wanted to screen scrape some HTML, for instance. But can you imagine someone saying "We want you to draw paths between points and they can't cross. And we want you to do it in XSLT"? I mean, you can do it... but... "not fun" doesn't begin to describe the pain.

I used XSLT on a project. I came from a functional mindset. XSLT is terrible and deserves its poor image.

SOAP, RDF and the semantic web clique, and other monstruosities of the 2000s gave XML a bad name but XSLT is nice. Indeed it would have been a nicer solution than responsive css to tackle the challenges of mobile devices.

I've done quite extensive XSLT development and like it for particular tasks, but I think XSLT's weak points are

1. It's Turing-complete, which means you can just use any other language for XML manipulation as well such as JavaScript (has DOM language bindings) or Prolog (rule/pattern based like XSLT) or maybe LISP (like DSSSL was). The benefit is that using a mainstream language gives you better mindshare and infrastructure such as APIs for DB access, IDE support for testing, etc. which I found inevitably necessary in every large XSLT project

2. XSLT 2 and 3 only has a single implementation (Saxon) by the same author as the XSLT spec itself - not my idea of a standard (and, in fact, not meeting W3C's criteria of at least two interoperable implementations).

XSLT works well if you need lots of literal XML content to be produced to the output, but will get verbose, degenerative, and awkward (priority rules) for highly dynamic content.

Amen. And while we're at it, let's throw some of the credit to XPath. Wouldn't you like concise, declarative traversal for your data structures? (Yeah, I'm sure somebody's already built it.)

I don't think I agree about responsive css, but that's another discussion.

I experiment with using XPath selectors to apply styling :D Can reach many things CSS selectors arent designed to reach!

I ended up writing a full compiler stack in XSLT for declarative, XML-based DSLs[0][1] and a few targets (mainly JavaScript and HTML). It didn't start out as that, but having already written basic HTML/JS generation from a simple DSL, it evolved from there.

It was originally written in XSLT 1.0 so that it could generate in the web browser, which had some serious limitations and was incredibly verbose. XSLT 2 is much less verbose, but obviously XML is verbose in general.

If I had to do it over, I'd use Lisp, but the functional and template-based style of XSLT made for very natural syntax-directed translation for the compilers. I still have the cruft of old XSLT 1 code (which was written when I was also _learning_ XSLT), but all things considered, it's not all that bad. Most of the pain points are the patchwork evolution of the project; done from scratch in XSLT, it'd be much more elegant.

And, like Lisp, XSLT can parse itself as data (sans xpath). That allowed me to use a semi-literate style (generate literate documentation from the sources), for example.

[0]: https://github.com/lovullo/tame [1]: https://github.com/lovullo/liza-proguic/tree/master/src [2]: https://github.com/lovullo/literate-xsl with example output https://mikegerwitz.com/hoxsl/manual/

I guess I'm dumb, but I have no idea what 'PGM' is supposed to mean in this context.

I'm guessing Program Manager, which is new-corporate speak for Project Manager.

The abbreviation suggests that it's Pro Gram Manager. As opposed to, say, an Amateur Ounce Manager.

Yes. Exactly. I can't remember what we actually called them at the time (in polite company).

Project Manager - Writes specs and documentation for individual features.

Product Manager - Figures out what new features or changes the product needs to better fit or find a new audience. Usually responsible for doing market research and analysis.

Business Product Owner - Similar to product manager, they own all changes associated with a company product. Position should only exist if product is so large, multiple product managers are needed for it. The product managers would then need to report to or clear their work past this individual.

Program Manager - Everyone above reports to this person. They own all of the products. And possibly oversee development as well.

Just to note, these definitions are no where near universal across organizations.

yeah, not even close. The two or three (only!) companies I've asked tended to have divisions like this, though, just with different names.

Program Manager[1]. i.e. too many generals and not enough soldiers

1: https://en.wikipedia.org/wiki/Program_management

I have no idea what half of that comment means (I'm not a programmer) so you aren't alone! (No insult meant to the original commenter!)

Yeah, sorry. It's terribly unclear :-) Basically there is a kind of markup called XML. You can define arbitrary hierarchies with it. It's very similar in shape to HTML (and at one point there was a big push to make HTML a subset of XML, but it failed). SVG is a graphics format that is defined in XML.

XSLT is a programming language. It's not the usual kind of programming language where you tell the computer what to do. Instead it's a bit like a pattern matcher. If you have X kind of pattern, then do Y action. It's difficult to do procedural kinds of things with it, but it is awesome for transforming one kind of data to another kind of data. It reads XML files natively and you can output any kind of data you want (although usually you output XML).

We had a strange team which was heavy in "idea people". These people had the title "program manager" (or something similar). The idea was that they would have ideas and tell the programmers what to build. In practice, they had pretty crappy ideas and then we had to find a way to make them not crappy.

None of the program managers understood technology very well, but they latched on to ideas with a certain tenacity. One of these people found out that XSLT could transform XML. He also heard that SVG was written in XML. Finally, he also knew that there were many databases (at the time) that stored the data in XML. So he thought that it would be easy (in fact, automatic) to use XSLT to transform the data in an XML database to SVG.

The idea was to draw a picture using Corel Draw and save it as SVG. Then you would alter the picture using the data in the database using the magic of XSLT. Unfortunately he did not understand that XSLT was a programming language, and no amount of explanation would illuminate the situation. He was absolutely sure that if we added XSLT to our software then it would automatically alter SVG images in an intelligent way.

We had to take that idea and make a viable product. What we did was to make an IDE that allowed you to connect portions of an SVG diagram to data in a database. You used snippets of XSLT to transform the data in the database to transformations in the SVG diagram. On top of that, we built a GUI API that would give you a full interactive experiences using SVG rather than HTML (so you could build entire apps in SVG and hook it up to live data in a database). It was actually pretty awesome (and I take no credit for that -- we had awesome people on the team).

Unfortunately the "magic pixie dust" of XSLT was do heady a draw for the program managers and they got it into their head that you could automatically route circuit board diagrams if you had an XML database of electronic parts. This was a terminal mistake (and we warned them many, many, many times that it was impossible).

At the time of the takeover (Corel was bought by a venture capital company called Vector), we were treading water and trying not to drown. They mercifully terminated us, but unfortunately buried a pretty wonderful suite of software.

Hope that was more understandable/informative!

Great times indeed. I did map-rendering and later (limited) map editing with SVG, XSLT and python 15 years ago. I even had something that resembled AJAX/REST in my stack, but that was not named in that way back then. I really learned a lot, even if some of it was as crazy as your thing.

Or, for the slightly more insane approach we (and by that I mean people in my organisation prior to my arrival) decided that XSLT was the right tool to transform XML to Python. XML to XML sounds like a walk in the park after that. :)

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact