- From: T.V Raman <raman@google.com>
- Date: Mon, 29 Jan 2007 09:03:16 -0800
- To: ht@inf.ed.ac.uk
- Cc: annevk@opera.com, raman@google.com, www-tag@w3.org
Henry, Here is my understanding of where XBL like beasts fit within the taxonomy of languages. I believe that the fact that today's XBL is used to declare the association between a given markup tree and a set of CSS styles and Javascript behaviors is an implementation detail. With respect to the role xbl-like languages play, their primary contribution is in being able to author the said association. So in summary, today's XBL spec which traces its roots to the Mozilla implementation talks about binding a markup tree to a particular styling language, CSS, and a set of event handlers authored in a specific implementation language, JavaScript --- it authors those associations using a very specific language for picking out nodes out of a DOM -- namely CSS Selectors. However all this is a reflection of a given snapshot in time -- and I dont believe these details to be intrinsic to the notion of a binding language as such. Henry S. Thompson writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Anne van Kesteren writes: > > > On Mon, 29 Jan 2007 17:22:32 +0100, Henry S. Thompson > > <ht@inf.ed.ac.uk> wrote: > >>> Not sure how you concluded that it's a "half way house" between > >>> xslt and javascript. > >> > >> Only that a moderately big deal is made in the introduction (the only > >> part I've read carefully so far :-) of the ability XBL2 provides for > >> effectively re-ordering children. . . > > > > The difference from XSLT for this particular scenario is that XBL > > doesn't actually alter the underlying DOM. The behavior XBL adds is > > also "optional": a document means the same with or without the > > associated XBL being applied. > > That's what I was trying to suggest -- not XSLT, but not just script > either. > > But your reply, which is echoed in the spec., confuses me. When I > point my browser at an XML document with an <?xml-stylesheet. . .?> > PI, e.g. [1], in what sense does anything "alter the underlying DOM"? > > The XML DOM is left alone, an new HTML DOM is built, and rendered. > > XSLT is spec'd to produce a new, distinct result tree, certainly not > to modify its input. . . > > ht > > [1] http://www.w3.org/TR/xmlschema-1/structures.xml > - -- > Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh > Half-time member of W3C Team > 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 > Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ > [mail really from me _always_ has this .sig -- mail without it is forged spam] > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > > iD8DBQFFviT0kjnJixAXWBoRAmX4AJ0Q5uNnn1oagEfdiUApQJA4sZ06rwCfdcvm > 5aDxzVbTnrD0ySwg3zs1Mzg= > =m4Nz > -----END PGP SIGNATURE----- -- Best Regards, --raman Title: Research Scientist Email: raman@google.com WWW: http://emacspeak.sf.net/raman/ Google: tv+raman GTalk: raman@google.com, tv.raman.tv@gmail.com PGP: http://emacspeak.sf.net/raman/raman-almaden.asc
Received on Monday, 29 January 2007 17:04:21 UTC