OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: XSL Debate, Leventhal responds to Stephen Deach

[ Lists Home | Date Index | Thread Index ]
  • From: "Simon St.Laurent" <simonstl@simonstl.com>
  • To: Paul Prescod <paul@prescod.net>, xml-dev@ic.ac.uk
  • Date: Mon, 14 Jun 1999 10:15:08 -0400

At 09:25 AM 6/12/99 -0500, Paul Prescod wrote:
>"Simon St.Laurent" wrote:
>> I'm afraid that there _is_ widespread dissatisfaction with XSL in general.
>
>Note that there is also widespread dissatisfaction with namespaces, RDF,
>XLink and XML itself.

Apart from Ted Nelson's excellent "Embedded Markup Considered Harmful", I
haven't seen much claiming that XML is a danger to the semantic Web the W3C
seems interested in building.  Dissatisfaction with particulars, of course,
is rampant.  That seemed to generate most of the violence over namespaces.
Dissatisfaction with the project?  I think XSL has a pretty good claim to
most of that.

>I thought that you liked XSLT. Did you change your mind?

I don't think XSLT is necessary, though I certainly can see where people
might want to use it for certain cases.  As far as XSLT's structure is
concerned, I can't say it thrills me.  It does work, however.

>I think that it would be more productive to separate concerns about XSLT
>from concerns about FOs. 

If FOs didn't exist, I think we could do that.  Unfortunately, because the
original drive of XSL was transformation into FOs, and not into a modified
tree annotated with formatting information, I don't think it's possible
unless you change FOs.

>Nobody solved the FOs considered harmful problems because they are
>*insoluable*. You cannot force people to put semantic markup on the Web.
>CSS can't force them to do so. CSS (by itself) doesn't even *allow* them
>to. XSLT allows them to (just as the DOM does). In my mind that is a Good
>Thing.

CSS+XML doesn't allow them to post semantic markup?  (CSS by itself doesn't
let you post _anything_, so I don't know what you're talking about.  HTML?)

The question is not whether FO's harmfulness is solvable, it's whether it's
an acceptable cost.  I see it as a cost that wouldn't have been incurred
had we stuck to annotation for formatting - while you could strip semantics
to SPAN and DIV if you really wanted, the whole selector mechanism of
Cascading Style Sheets discourages such practice.  It would have taken an
extra level of processing to do that stripping.  

Output to HTML from XSLT is ugly, but it's an ugly we're already used to
and which XHTML is smoothing out to some extent anyway.

>20/20 hindsight is great but don't we all as individuals have the
>responsibility to move on to technical issues instead of talking about how
>things should have been done three years ago? 

In this case, 20/20 hindsight for the XSL community is an "I told you so"
for the CSS community.  Take a look at the early battles on XSL-list and
you'll see that I'm saying nothing original here - these arguments were on
the list before I even subscribed.  Doesn't it seem like our responsibility
to learn from the lessons of _one_ year ago rather than racking up the same
kinds of problems again and again?

>Please, let's talk about technology! XSL FOs are very much based on CSS
>properties. Where do you see the conflicts occurring? What exactly is your
>complaint? If we changed the prefix from FO: to CSS: would that address
>your concern?

The problem, fundamentally, is that XSL FOs are an element vocabulary,
while CSS properties lived inside attributes or style sheets, without
disrupting the original element names.  Make FOs properties rather than
elements, and maybe we can talk.  Of course, this would mean reexamining
XSL FOs from a CSS perspective, and I'm not sure that's a technical
proposition the XSL community would enjoy for political reasons.

>> XSL could have looked very different had cooperation between XSL and CSS
>> begun earlier, but the core functionality you keep demanding would probably
>> have worked about the same.
>
>It would look very different *how*? What technical proposal are you
>making?

See above.  Transformations to an endpoint that still had as much semantics
as the original - formatting properties represented as attributes rather
than elements - might have avoided lots of the 'considered harmful' issues
that you want to ignore.  I think inclusion and sequence are the only large
problems such an approach presents, and I don't think they're insoluble.
(Unlike FOs' harmfulness, for example.)

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)






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS