Re: SAX parser for CSS (Was: Conversion from xsl to xs

Eric van der Vlist <vdv@xxxxxxxxxxxx> wrote
> Joerg Pietschmann wrote:
> >>>It ought to be a good time to invent XCSS :-)
> 
> As many people on this list, I have also been thinking about this and,
> IMHO, the parsing will not be the difficult part (and a SAX parser or a
> XML vocabulary are equivalent)
Correct. However, There are multiple mappings from the CSS data model
onto a XML vocabulary. The differences are in details only, but details
matter.
I used
<!ELEMENT css (styledef*)>
<!ELEMENT styledef (selector+,style+)>
<!ELEMENT style (name,value)>
<!ELEMENT selector (element|attribute|class)>
<!ELEMENT element (name,(child|descendant)*,attribute?)>
all else are PCDATA. This is of course a subset only both of the CSS
data model and of the CSS selectors.
Apart from the names, there could be a heated discussion whether
styledef should be defined as above or rather as (selectors,styles)
with selectors being selector+ and styles being style+ (which is
easier to process with XSL in some cases according to my experience).
Furthermore you'll notice that i used a generic approach which would
allow the concrete style tags to change without changes in the DTD.
Also, the element value, as sepcified above, may actually be a list of
values (for example font family names) which requires a second parse
pass. Therefore there could be another discussion whether it should be
value+ instead.

> and what is much harder is to match the
> CSS selectors and XPath...
[snip, see article:]
> http://lists.w3.org/Archives/Public/www-style/2001Jan/0091.html

While short, the article is enlightening.
My suggestion:
- XMLify CSS
- use XPATH for matching elements
For example
<css>
  <styledef>
    <selector match="td">
    <selector match="table/th">
    <selector match="table//td">
    <selector match="tr[@class='toc']">
    <selector match="*[@id='sans-serif']">
    <style><name>font-family</name><value>Helvetica</value></style>
  <styledef>
</css>
While the paths above could be mapped onto CSS selectors (unless
i made mistakes...), with XPath we could specify much more complex
stuff. Pseudo formats (a:visited, p:first-letter) don't fit in, but
could be handled by another attribute of the selector element.
I don't think there is a real need to retrofit CSS syntax into XML
by proposing the "Stylable DOM". Especially as long as it is a pain
to operate multiple DOM implementations in the same application.

In order to bring it on topic for the XSL list, i want to note that
the proposed form would be most useful if XSLT has the capability
to dynamically evaluate XPaths...in the result tree!

I know this should better go to the xml-dev list, but i don't have
time to track yet another mailing list...

Regards
J.Pietschmann

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