- From: Kurt Cagle <kurt@kurtcagle.net>
- Date: Fri, 03 Sep 2004 11:05:33 -0700
- To: Anne van Kesteren <fora@annevankesteren.nl>, www-svg@w3.org
Anne van Kesteren wrote: > XBL is already used in Mozilla and not really as an implementation layer > between SVG and XForms, since those specifications are not (yet) > supported by Mozilla and will probably only be supported through a > plugin mechanism. > > I know there is some support for SVG already, but XBL was implemented > before that and is used for form controls and MARQUEE to name some > examples. The support for XForms/SVG was only one role for sXBL, something I tried to imply. There are of course many others. The XForms compliance argument, especially in light of the recent announcement on the part of IBM/Novell concerning Mozilla XForms support, should be seen as a forward looking one, rather than one in line with current implementation support. Mozilla XBL precedes a fair amount, including many of the more recent XML component inclusions within Mozilla. I see a W3C implementation of XBL to be a superset of the functionality of Mozilla, not a direct legacy copy. >> b) Most current "complete" SVG implementations exist in an environment >> when such XPath support already exists (Java, COM, .NET, Rhino, >> Mozilla Seamonkey, libXML, etc.) and as such the necessity for >> vendors to build their own XPath implementations is somewhat >> reduced. > > > You forget that sXBL will become XBL which is not SVG specific. So UAs > who might implement XBL might not have support for XPath. I think this is a broader UA issue - SVG is the most immediate test-case, but an XBL implementation for XHTML or even XSL-FO would have exactly the same issues being raised. One of my biggest complaints with the older RCC implementation was that there were significant portions of XML data (most notably attributes) that were simply not referenceable from within a context block *without the use of ECMAscript*. The whole reason for XBL, as I see it, is to minimize the amount of unnecessary imperative coding necessary to create a UI and to move more of that coding into the more abstract XML basis. Thus, with XBL, you are already predicating that the UA DOES support some form of scripting language, most likely ECMAScript. There are already, in most UAs, these ECMAScript implementations, though because of versioning issues you run into some interface incompatibilities. Broadly, these same interfaces that support ECMAScript should be sufficient to support XPath, for which there are also numerous freely and commercially available implementations. This argument may not have been valid two years ago, but I cannot at this date think of any host platform that supports one but not the other, especially as XPath parsers are part of the Java core, exist within PHP, have numerous open source and commercial C++ implementations, and so forth. Of the primary UAs currently available, only Opera does not have an XPath implementation, and they will be providing this (and XSLT support) within their 8.0 releases early next year. As mentioned previously, the one area I can think of where a full XPath implementation would be infeasible may be in the wireless embedded market, though from conversations with Nokia engineers, I know that a subset of XPath is planned for at least their line. Given that there are still only a handful of fully conformant SVG Viewers, I expect it will take a couple of years before the XBL spec fully percolates through the industry. Following present trends for the pervasiveness of XPath in the industry, this support will be there in the few niche markets where XPath does not exist long before full XBL implementations make their way to market. > >> d) I have often used the complexity of XPath as one of the reasons for >> not incorporating it in SVG. However, it has been my experience in >> teaching classes on SVG and dealing with readers as a technical writer >> that if they are sufficiently savvy to master rudimentary SVG >> skills, they can easily master rudimentary XPath. > > > I don't see why this is an argument for XPath over CSS. One of the overriding principles of any open standard is simplicity - if it requires sophisticated technical knowledge to make basic features work, then no matter how freely available the specification, it will not be adopted by industry. XBL is fundamentally about data binding (take a look at my blog at http://www.metaphoricalweb.com in the next few days and I'll explain this in much greater detail) - building bindings between a configuration of data (as XML) and some representation of that data (as a component implementation). Data binding can be an incredibly complex process and consume a healthy chunk of any application developer's project cycle - it's why the proprietary platforms such as ASP.NET or Cold Fusion are so successful, since they recognize this aspect of web development. CSS is not a data binding language, save in a very loose sense. It has no concept of an object's position, for starters, places a strong requirement that there is a one-to-one correspondance between the order of the initial data and the order of the final presentation, and is unable to perform subordinate queries (such as checking to see that a given set of attributes combined have specific values). Most UAs that implement CSS barely have support for the id attribute let alone more complex queries. XPath has become a common (indeed, with the advent of XML from SQL data stores, the most common) way of performing fine-grain data queries and manipulation among developers. While complex queries within XPath can challenge even an XPath guru, most queries within XPath are simple enough that they require little extraordinary awareness of the technology (and indeed, mirror CSS selectors reasonably closely in that regime). XBL is complex. It requires the ability to abstract potentially recursive structures, and in that sense is not dissimilar from XSLT. Your typical FrontPage user probably won't be able to write XBL. Your typically web developer, however, will, and that developer is much more likely to be conversant with XPath than with higher order selectors in CSS *because they are already using it to perform data binding within their own applications*. Additionally XPath is in general much easier to encode within an application so that automated editors generate it than is the case with CSS. The CSS inheritance model is a real pain to implement, in great part because of the broad, amorphous nature of its selectors. Once automated, it really doesn't matter whether or not your FrontPage user needs to know about XBL, because it will be generated for them automatically. Your web devs and UA application developers will find it better to use a known solution (XPath, and preferably not some arbitrary subset of it) than to have to learn yet another selector logic, one that is less suited to the tasks at hand. >> e) I would recommend that you mandate the full XPath solution for SVG >> Basic, and the reduced set XPath solution for SVG Tiny. I understand >> the memory requirements that SVGT targets have, making it difficult >> to implement the full set, but a simnple tree walker parser can >> readily be implemented (and indeed probably already exists). > > > Where is the argument or reason? You will need to implement a selector technology, regardless of whether it be CSS or XPath - even "no" selector technology choice within an xbl context is an implicit chose for a defacto nodal solution, albeit a limited one. From my own experiences dealing with the development of SVG UI components (and I've written two books on same, SVG Programming for Apress and SVG & X3D for Springer-Verlag) it is better to have a robust binding technology than to have a limited one, as the benefits of a limited one (greater adoption by beginning users and resource allocation within the UA, or in the development process) are usually more than outweighed by the fact that a weak standard will not be adopted by more fully trained application developers and that resource allocation problems are, at least for the foreseeable future, generally trumped by increasing power in the hardware very quickly. A robust binding language (which XPath is and CSS is not) will gain many more adherents, however, as developers strive to create ever more sophisticated UI's through something like XBL. Finally, there is a profound difference between the standards that the W3C creates and the de facto standards associated with efforts by companies. The W3C standards are more like goals to be reached in order to achieve the technology than statements of de facto implementations. By choosing CSS selectors, you give validation to a standard that many of us frankly would like to see radically revised, as it predates XML and forms an awkward counterpoint to it. > >> f) A quick argument against using CSS Selectors - The CSS selector >> model beyond the simplest matching mechanisms is generally not well >> understood by more than a small proportion of the web development >> universe, in great part because the browser with the largest market >> share does not support that functionality properly. > > > That problem has been solved[1] and [2] I think that more (a lot more) > people know CSS Selectors than people know XPath. No,not really on both [1] and [2]. IE6 is closer to the W3C CSS spec than 5.5 was, but it still lacks support for several key implementations in CSS 2.1, especially in the area of pseudo-classes and subordinate bindings. [2] I think we're at odds in identifying where the target market for XBL is - you see it as being more readily adopted by web designers, and I see it being well within the domain of web developers. Web Designers largely use pre-existing tools to generate their content - they may know the rudiments of CSS, but generally they prefer to let their editors create content and handle all of that through WYSIWYG interfaces rather than putting this information in by hand. Developers, on the other hand, tend to work with CSS via the mechanism of DOM style interfaces (or sometimes, but much more rarely, DOM style class interfaces) rather than dealing with it in stylesheets directly. Moreover, most web developers have learned XML out of survival, and learning XML usually entails learning XPath. XBL necessitates understanding namespaces, and I would contend that anyone sufficiently savvy to work with namespaces on a regular basis will have at least rudimentary experience with XPath. Concerning IE7 ... this is welcome news, but doesn't really change my arguments ... the previous lack of standardization on Microsoft's part means that the intricacies of CSS are still not consistently understood by most developers, who have chosen to take a much watered down subset to attempt to maintain compatibility between versions. > >> Again, this comes from experience dealing with readers and students >> when I teach CSS classes. Moreover, the CSS model requires the use of >> certain reserved characters (the ">" greater-than character) to >> facilitate its operation for the more sophisticated operations that >> will cause compilation errors with many XML parsers. > > > XPath has exactly the same. This was an error on my part. I've been dealing with XSLT2 and XPath2 for some time, and forgot that XPath1 does not have the same level of support. I would be interested in seeing compelling arguments for use of CSS rather than XPath here. So far, most of the arguments seem to come down to ease of use, which, as I've pointed out, is probably less important here than power and flexibility, but I'm open to alternative viewpoints. -- Kurt Cagle -- http://www.metaphoricalweb.com
Received on Friday, 3 September 2004 18:05:34 UTC