RE: About the source library

["Didier PH Martin" <martind@xxxxxxxxxxxxx>]

Hi Normand

------------------------------------
/ "Didier PH Martin" <martind@xxxxxxxxxxxxx> was heard to say:
| a) XSL lacks a procedural language. Actually the "function" support is
| insufficient for a lot of tasks. Just take an example from this morning.
| Someone posted a DSSSL script that removes trailing spaces. XSL won't be
| able to do that until complete integration of a procedural language or an
| expression language (the actual JavaScript inclusion is too limited)

My recent experiences writing XSL stylesheets for DocBook
(http://nwalsh.com/docbook/xsl) leave me less concerned about
this than I used to be. XSL's more expressive selection syntax
reduces the need for procedural programming. And recursive calls
to named templates can do quite a lot ;-)

<Reply>
Yes Normand I agree that with XSL you can do quite a lot. But still remains
that some tasks are still hard to do with it, if not impossible. This said,
XSL is an excellent language and is very versatile.
-------------------------------------

| b) You'll never be able to transform SGML documents. XSL is for XML only.

Nonsense. XSLT is a tree-to-tree transformation language. There's
no reason an XSL processor couldn't load SGML documents and process
them.
<reply>
No problem, it will be a proprietary implementation with a SGML parser
instead of a XML parser. However, the probability is very low that we'll see
a XSLT engine that process SGML (if there is one, keep that mail Norman to
remind me that if this happens I'll owe you a bottle of wine :-)
-------------------------------------

| Off course if we make the inference that SGML will disappear and that XML
| will cover the planet. This feature is obsolete and unnecessary. And we'll
| also have to make the inference that Hytime will disappear and that topic
| maps will be a death born child.

What features of HyTime are not possible in XML?  Remember, XML is SGML.

<reply>
Simple, full SGML architectural form processing ;-) Also, some Hytime
constructs are based on the terrible (in the XML world) - 0 Omittag (yes I
said it, I'll rest in the eternal flames :-)
 Keep in mind that W3C is creating a competing linking spec (XLL and
XPointer) and that XML and Hytime is probably less (a lot less in fact)
probable than XML and XLL/XPointer
-------------------------------------

| elements. The question is: how long will it take for XSL to have a full
| expression language or that a procedural language like JavaScript can have
| full access to the document's elements? Or will it ever do?

You've got pretty full access now.

Not totally, it is only in a function form. However, I should say that most
of style or transformation languages (except Omnimark) have the same
limitations. Also, the ECMA script won't have as rich function as for
example omnimark scripts. But, I should say however, that now that ECMA
script functions can be included in XSL scripts, you can do a lot more than
before and for a lot of people maybe more easily than with other languages.
So, yes, now that ECMAscript is included as function, we can do a lot more
than before. And in the same vein, now that XSL is splitted in two, it can
be used more easily for server side transformation (a good thing for a
certain time).

So, Norman because XSL is like a moving target or sometime like a wet soap
trying to escape :-) it is changing often. The last spec was improved a lot
(from several perspectives). We should now talk, because of this moving
target, of a very short opinion life cycle :-)

Regards


 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist