Re: SVG, CSS and XSL

Although this starts out as an XSL compatibility issue, there are a lot of
larger issues to consider so anyone interested should follow-up to
www-svg@w3.org. You can subscribe by sending mail to
www-svg-request@w3.org.

Chris Lilley wrote:
> 
> > If SVG had followed that
> > document's lead then SVG would be a reasonable output format from XSL.
> 
> When choosing between an established Recommendation and an unimplemented
> note with no actual benefit ... erm, that wasn't very difficult.

I don't care what the status of the note is, if it makes sense it makes
sense.

It's a question of proper design, not prior standardization. XML has a
feature for attaching named properties of all kinds to elements. CSS was
designed before XML. It isn't properly integrated with XML's way of doing
things. That note shows how CSS could be made XML friendly. SVG ignores
that lead.

Anyhow, the most compelling argument against the current way of doing
things is http://www.w3.org/TR/WD-SVG/attrib.html . The "criteria" are
confusing and complicated. I dread teaching and writing about SVG already.

Also, the speci doesn't seem to differentiate between *syntax* and *data
model*.

It says: "By defining these attributes as CSS properties, we are making
progress toward commonality across multiple languages." I thought that the
point of the "W3C formatting object model" is that properties can have
multiple syntaxes and logically boil down to the same thing. That's why I
have argued that CSS and XSL FO do not have to be in competition. They are
different views on the same data model. SVG doesn't take advantage of
that.

> If you can show that XSL could do the necessary transformations to, for
> example, go through a spreadsheet expressed in XML and generate some
> standard business graphics of those numbers (ignoring the style part for
> now, as I said you can always use a link) then I might be more
> convinced.

I don't know enough about SVG now to say what is possible. I do know that
compatibility with XSL is a requirement of SVG. I would have thought that
compatibility with XSL as an output would have been included.

If simple SVG drawings can be structural enough to hand-author without
worrying about exact pixel locations, then they will be structural enough
to be the output of an XSL process. I'm pretty confident that DrawML is
sufficiently structural to be an output of an XSL process. If SVG adopts
the high-level constraint features of DrawML then I'll bet that it will be
useful as a transformation target.

> As it is, that looks like a prime candidate for a DOM program rather
> than an XSL style sheet. I have reason to believe that XSL is not wells
> suited to this particular task.

Fine, so let's consider the example of a DOM program. No standardized
version of the DOM supports parsing and building CSS styles. A current
working draft specifies how to do so *for HTML documents* but not for XML. 

We could work around this with some other standardized hack. We could
extend the DOM so that any attribute in an XML document could be a "style"
attribute. Style attributes could be parsed according to CSS. Now the XML
DOM has a dependency on CSS. Urck. That leads to a host of other minor
problems.

Then an XML query language comes along. I want to query my SVG repository
based on CSS properties. If they are XML attributes that is easy. But if
not, I have to invent a CSS or SVG-specific query language.

Then along comes the XML Schema language. I want to describe SVG
constraints in terms of XSL. Perhaps I want to define ordinary constraints
(i.e. font-size should be a number followed by a unit) or perhaps I want
to define an SVG subset. Well, I'm pretty sure that the XML schema
language won't support CSS's concept of property.

At some point the impedence mismatches will become so painful that CSS
will either move to an XML attribute model or be replaced by something
that does.

 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco

If you spend any time administering Windows NT, you're far too familiar 
with the Blue Screen of Death (BSOD) which displays the cause of the 
crash and gives some information about the state of the system when 
it crashed.  -- "Microsoft Developer Network Magazine"

Received on Saturday, 13 February 1999 14:37:35 UTC