Re: sXBL draft comments

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