And a fine site it is too. Keep up the random rants!
Actually you hit the nail on the head when you speak of using Scheme-type syntaxes only when no boss is breathing down your neck. It is perplexing that it has to be this way, as authoring Scheme is incredibly simple compared with authoring XML/HTML. For starters, you can use standard bracket-matching in your favourite editor and don't have to fork out for a special editor (XML Spy, Dreamweaver etc.)
The irony of course is that XSL is derived from DSSSL, which is in turn a derivative of Scheme. Except that XSL loses because a) It's not Turing-powerful and b) It has the same stupid syntax as XML (which people still seem to tolerate; even though they complain about Lisp's round brackets, XML's angle-brackets are obviously more in vogue right now)
I noticed with interest a few months back the curl project which was a step in the right direction but had flaws of its own.
Personally my feeling is that Scheme/Lisp will always be stuck firmly outside of the mainstream for at least another 40 years because it lacks instant appeal, particularly to those without a CS background. I think it is a shame even to relegate it to processing XML; it should really be replacing both XML and XSL!
It is a common mantra of the XML community that it is advantageous to seperate style and content, but there are a few snags to this.
Firstly, stylesheets are not Turing-complete, and hence are not able to render all the types of transformation that you may want. Therefore, you do have to consider how your data is to be formatted when defining your schema.
Secondly, there is by no means a hard and fast rule about what constitutes style and what constitutes content. XML/XSL provides a two-level delineation that unnecessarily constrains ones method of working.
LaTeX fares no better on either count.
I would suggest using something like LISP or PostScript, which both have a wonderfully regular syntax, are easy to edit, and can represent data and semantics in a single continuous conceptual space... leaving it up to the designer to have a whole hierarchy of levels, from the top-level (most declarative) layer, to the bottom-level formatting layer.
Of course, people will end up using XML because it is seen as the "standard" now, which is quite depressing really.
Slashdot Mirror
(Slashdot
(Editor '((type Full-time)(name cmdrTaco))))
If you really want attributes you can do it Common-Lisp &key style:
:type Full-time :name cmdrtaco))
(Slashdot
(Editor
Though of course you'd need to roll your own &key handling.
And a fine site it is too. Keep up the random rants!
Actually you hit the nail on the head when you speak of using Scheme-type syntaxes only when no boss is breathing down your neck. It is perplexing that it has to be this way, as authoring Scheme is incredibly simple compared with authoring XML/HTML. For starters, you can use standard bracket-matching in your favourite editor and don't have to fork out for a special editor (XML Spy, Dreamweaver etc.)
The irony of course is that XSL is derived from DSSSL, which is in turn a derivative of Scheme. Except that XSL loses because a) It's not Turing-powerful and b) It has the same stupid syntax as XML (which people still seem to tolerate; even though they complain about Lisp's round brackets, XML's angle-brackets are obviously more in vogue right now)
I noticed with interest a few months back the curl project which was a step in the right direction but had flaws of its own.
Personally my feeling is that Scheme/Lisp will always be stuck firmly outside of the mainstream for at least another 40 years because it lacks instant appeal, particularly to those without a CS background. I think it is a shame even to relegate it to processing XML; it should really be replacing both XML and XSL!
Surely you just close one eye and move the other?
It is a common mantra of the XML community that it is advantageous to seperate style and content, but there are a few snags to this. Firstly, stylesheets are not Turing-complete, and hence are not able to render all the types of transformation that you may want. Therefore, you do have to consider how your data is to be formatted when defining your schema. Secondly, there is by no means a hard and fast rule about what constitutes style and what constitutes content. XML/XSL provides a two-level delineation that unnecessarily constrains ones method of working. LaTeX fares no better on either count. I would suggest using something like LISP or PostScript, which both have a wonderfully regular syntax, are easy to edit, and can represent data and semantics in a single continuous conceptual space... leaving it up to the designer to have a whole hierarchy of levels, from the top-level (most declarative) layer, to the bottom-level formatting layer. Of course, people will end up using XML because it is seen as the "standard" now, which is quite depressing really.