Subject: CSS selectors for pattern syntax. Why not? From: Ray Cromwell <ray@xxxxxxxxxxxxxxx> Date: Wed, 19 Aug 1998 13:11:21 -0400 (EDT) |
> > 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: New/old pattern syntax, why can, James K. Tauber | Thread | Re: New/old pattern syntax, why can, Paul Prescod |
HTML backend, Pasqualino \"Titto\" | Date | RE: Comments on XSL Draft, Gavin Thomas Nicol |
Month |