CSS selectors for pattern syntax. Why not?

[Ray Cromwell <ray@xxxxxxxxxxxxxxx>]

> > Is Xpointer intended to solve the problem of patterns?  It
> > seems to me that patterns in XSL are much more complex than XPointers.  If
> > XPointers could be used then I would very much agree with using them
> instead
> > of coming up with another syntax.
> 
> XPointers can't really be used for XSL and XSL patterns can't really be used
> for XLink addressessing --- AS THEY CURRENTLY STAND.
> 
> I'm interested in exploring the possibility of expanding both to form a
> superset tree addressing language.

What about CSS selectors, and why weren't they considered for XSL? Ignoring
the one illegal character ('>'), using CSS selectors would have the benefit
of unifying the two technologies in the minds of developers.

A tool could generate a CSS selector for the user, and optionally spit out
either a CSS or XSL using the same selectors.  I have actually been
working on a servlet processing engine similar to docproc which can
handle XML +  CSS, XSL, or even DSSSL (not done yet) by storing
patterns in a higher level, and then serializing them out to 
CSS or XSL (the old draft)

I user could also develop Style-Rules using a CSS editor, and then
copy the same selector into an XSL app if he needed to do some
tree processing.

I would propose some simple modifications to CSS syntax. Add '/' as a
synonym for '>', and add more pseudo classes for position qualifiers.
Throw in an ancestor operator that is not "space", perhaps "..."



I don't think '[]' should be as overloaded as they have it in the XSL spec
right now. I think it should be used for attribute qualifiers only.

The new XSL patterns would look like

chapter / section[title="Introduction"] / contributors / name:first-of-type 

optionally encoded as

chapter > section[title="Introduction"] > contributors > name:first-of-type 


an ancestor pattern previously encoded as

chapter // name

would become

chapter / ... / name

optinally encoded as

chapter name


I think CSS's use of [] for attributes and pseudo classes for qualifiers is 
much more readable than XSL's heavily overloaded [] syntax -- especially
the sibling / child qualifier!



I still think that

<element type="chapter">
  <element type="section"> <attribute name="title" value="Introduction"/>
    <element type="contributors">
      <target-element type="name" position="first-of-type"/>
    </element>
  </element>
</element>


Is pretty clear, and certainly more machine readable. Editable by any
standard XML tool, and saves people the trouble of having to implement
yet another parser. Recently, I implemented a parser for CSS, XPointer,
and a custom language, and I'm getting a little weary of it. I thought
XML was supposed to save me from this?





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