Lists Home |
Date Index |
- From: Paul Prescod <firstname.lastname@example.org>
- To: email@example.com
- Date: Tue, 22 Jun 1999 07:38:34 -0400
"Simon St.Laurent" wrote:
> 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.
It isn't an extended detour. People often need to display images based on
computed values that are NOT represented as links. I gave one example in
my last message and there are many more.
Linking is one thing.
Displaying images is a separate thing.
Displaying images referenced by links is a combination of these features.
> >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.
Okay, fine, so you are *in favor* of destructive transformations. You just
"semantic web" rhetoric then?
> >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'.
Sorry I wasn't clear: I was talking about Hakon, Bos and Lilley.
> 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.
They already do! The DOM can be used on the client OR server side just as
XSL can. There *is no difference* except syntax and processing model. The
DOM can be just as destructive as XSL can. The DOM can be used to disable
semantics just as XSL can.
> 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.
Argh. The technology for disabling the semantic web has been available
since CGI. Insofar as XSL can be used within CGI-like technologies, XSL
can be used to disable the semantic web. So can the DOM. If you want to
argue that XSL does nothing new, then that's one thing.
But if you are going to pursue this "disabling the semantic web" stuff
you'll have to show that XSL is somehow better at doing so than the DOM,
which you seem to think is just fine.
Paul Prescod - ISOGEN Consulting Engineer speaking for only himself
[Woody Allen on Hollywood in "Annie Hall"]
Annie: "It's so clean down here."
Woody: "That's because they don't throw their garbage away. They make
it into television shows."
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)