xml-dev - Re: XSL Debate, Leventhal responds to Stephen Deach

["Simon St.Laurent" <simonstl@simonstl.com>]

At 08:40 PM 6/21/99 -0400, Paul Prescod wrote:
>"Simon St.Laurent" wrote:
>> I'm afraid - in my opinion at least - that this is a gross underestimation
>> of the capabilities of CSS.  While CSS does not at present provide an easy
>> way to display graphics, this is:
>> 
>> a) easy to add
>
>I agree.

Glad to hear that.

>> b) dependent on XLink, which is thus far a no-show.
>
>Dozens of simple style languages do not have any dependence on a
>particular linking standard in order to implement graphics. All you need
>to do is to be able to say what attribute is the graphic referencing one!

Yes, you could do that.  But that kind of decoupling is neither necessary
nor an especially good thing.  I see no reason for CSS to develop its own
linking mechanisms in advance of XLink, apart from the fact that the XLink
spec is 15 months+ old.  You seem to be in favor of making every spec as
powerful as possible on its own terms, without consideration for how it
should integrate with other specs later.  I would much rather build specs
as an integrated whole, rather than create features that will take
developers on extended detours later.

This may just be a philosophical difference, but it underlies many of the
points in this debate.

>> Navigational mechanisms and cross references have similar dependencies on
>> XLink, but I see no reason why they should cause 'severe problems'.
>
>The navigational mechanisms that I mean have no dependencies on XLink.
>Tables of contents, indexes, forward and back buttons. These can (and
>should) all be generated with a *transformation language* but cannot be
>with an annotative language.

I can do all of that now with the DOM and simple scripting.  I don't need
XSL to do that by any means.

>Let me give you a real-world problem. Authors make links to images
>on a corporate website. Every image has an associated XML document.
>foo/bar/baz.gif has an associated foo/bar/baz.xml with metadata about the
>image, including a caption. With a transformational technology like XSL or
>DOM+Javascript, I split the string, reach into the associated XML document
>and retrieve the caption. I transform it into a peer element of the
>graphic. How do I handle this problem with CSS? 

Easily.  You use DOM for your processing, and CSS for your presentation,
rather than mixing your tree-building and formatting.  CSS doesn't exist in
a vacuum.

>Note that Leventhal is NOT against destructive transformations. Nor are
>any of the CSS designers that I know of.

Hello, my name is Simon and I'm a 'CSS Designer'.

Destructive transformations _on the client_ I can accept.  Encouraging
destructive transformations _on the server_ is disturbing at best, and not
something I think we should be promoting - and I strongly hope the W3C
doesn't encourage that by providing tools for doing it.  If that means
reconfiguring XSL, that's fine. That's what working drafts are for, after all.

XSL in its present form is unnecessary, doing nothing new (the Leventhal
argument), and brings with it new dangers (an easy move away from the
semantic Web).  To me, that's a pretty good case for passing on XSL.



Simon St.Laurent
XML: A Primer / Building XML Applications
Inside XML DTDs: Scientific and Technical (July)
Sharing Bandwidth / Cookies
http://www.simonstl.com

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)