Re: Beginners question: Koala XSL-Engine and <xsl:process select>

["Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>]

[Tyler Baker]
> This of course makes sense if XSL is supposed to be able to handle
> nodes other than just element nodes.  I guess this all boils down to
> whether XSL should just be something for content transformations or
> something much more complex which handles comments, PI's, and all of
> that other stuff that for the most part has nothing to do with
> presentation.


[Chris Maden]
> I'd like you to come tell my production editors that PIs have nothing
> to do with presentation.  They're exactly where information like
> page-breaks belong.
>
> The current draft says:
>
>      Issue (pattern-pi-target): Should it be possible to have a
>      pattern that matches a processing instruction?
>
> I think that it should, and I think that it'll probably go that way.

[Tyler Baker]
>This is one way of doing things here.  I am just arguing here to keep XSL
>(and XML for that matter) very, very, simple.  If XML and XSL are not very
>simple, there is no reason to use it as working with it will be about as
>bad as working with native document formats.  I feel sometimes that people
>simply want to keep adding things to a language (programming or otherwise)
>simply to suit their particular application at the time without ever
>considering the possible negatives of doing so.

Well, it is true that requests for adding features come from trying to make
XSL "suit the particular application". As long as this application falls
within the intended range of applications for XSL, what is wrong in that?
Real world applications _must_ be the driving force behind the language
design for it to be usable in writing such applications.

>As you keep adding
>complexity you are continually increasing the learning curve for others to
>use your creation and in the end it will all fail because the number of
>dollars and time it takes to get people up to speed with the language you
>are creating will be greater than any dollars you save by using the
>technology.

There are also the dollars and time it takes to work around missing
features. If the need is common enough, adding a feature makes a language
easier to use, instead of harder. Also, adding one general feature sometimes
makes several special-case features redundant so they can be removed. Doing
this right (which is admittedly difficult) actually reduces the language
complexity. In practice, once there's an existing code base, it is
impossible to do, so it is vital to get the feature set right before the
first version of the standard is frozen.

As for the particular feature (pattern-pi-target), there are good examples
of common XML-to-HTML conversions which require it (generating table of
contents, indices, figure tables, and so on). The workarounds are much more
complex then the suggested XSL extensions. The tradeoff seems to favor
adding this feature, so far.

>The main success of Java I feel is that a C/C++ programmer could read the
>Java Language Specification and get up to speed in a matter of weeks.  XML
>and XSL, even though they are not programming languages, in a lot of
>respects are somewhat more complicated.  I just plead with those
>responsible for maintaining XML and XSL, that things do not get any more
>complicated than they already are.  If you try explaining XML and XSL to
>someone who is of intermediate computer experience and you start sounding
>like a geek to them, that is a good sign things are too complicated.


Learing Java in weeks (or days) is possible only because learning C/C++
takes months or years. SImilarly, learning XSL in days would require having
appropriate background - in this case, in HTML and a smuttering of some
computer language.

I'm buffled by the expectation that XSL would be usable by computer
illiterates. Where did this idea come from? Is it because of XSSL? Doing a
style sheet is a far cry from conversion of arbitrary complex data
structures to HTML format. Restricting the second to features required by
the first is a waste of time.

Oren Ben-Kiki


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list