Re: Decouple XBL2 From CSS

Ian,

> Relative to Selectors? Yes, XPath is hardly used at all. In a recent study
> of 667416 files, containing 862606 <link> elements with a type attribute,
> 681381 had type="text/css", and 6847 had text="text/xml" or
> "application/xml", which covers RSS, Atom, and XSLT. (The same sample had
> 736036 <link> elements with rel="stylesheet". The de facto default type=""
> value for rel="stylesheet" in browsers today is text/css.) I found exactly
> one file that claimed to use the XForms namespace in this sample. (I
> didn't check to see if this file actually used XForms; it should be noted
> that there are a surprisingly large number of pages on the Web that claim
> to use a whole host of namespaces but actually don't use any. Thus, this
> hit could have been a false positive.)

This is getting surreal...did you also make the surprising discovery
that in 123456 pages written in German, none of them were actually
written in English!


> So based on this research, I conclude that most authors have used
> Selectors (typically as part of CSS), and nearly no authors have used
> XPath (whether as part of XSLT, XForms, or scripting).

Mmm...I wouldn't go so far as to call that 'research', Ian.


> > Anyway, the request for XPath selector support *is* actually being made
> > by authors and application builders
>
> It's being requested by a very small (though very vocal) minority. If you
> allow a spec's design to be led by the vocal minority you end up with a
> spec that is not useful for the silent majority. The W3C process is very
> well tuned towards creating such specifications, and the TR page is full
> of them. I have no intention of letting XBL2 fall into that trap.

But it is being driven by the vocal minority...you.


> > and I think it would be wise to design XBL in such a way that the
> > binding *selection* process is distinct from what the bindings actually
> > do. If an implementer chooses to only support CSS selectors then that's
> > fine, and doesn't bother me at all.
>
> If you are ok with having two non-interoperable versions of XBL2, one with
> implementations that use Selectors, and the other with implementations
> that use XPath, then I encourage you to take the XBL2 specification,
> change its name to something else, change the "Selectors" parts to using
> XPath (this will require quite substantial changes, including specifying
> error handling behaviour for XPath, and profiling the allowed expressions
> for XPath to exclude things that don't act like pattern matches), and
> finally publish it. The XBL2 specification is available under a Creative
> Commons Attribution Share-alike license for precisely this purpose.

But if I was going to go to that trouble, I might as well create a
new, slim-downed version that doesn't set itself apart form other
languages, and doesn't bring the legacy of XBL 1. But I've always
taken the view that the very act of adopting a standard is better than
the standard itself being perfect...Brunel discovered that, albeit in
a negative way. So I would prefer to see XBL 2 usable in *many*
places.

(I'm not ruling out producing something else though, just saying it
seems unnecessary.)

Also, many standards allow themselves to be used in other places, and
I see no problem at all in having the binding mechanism be distinct
from the functionality provided by the bindings.


The following points you made in response to Antoine's email:

> Selectors have been in a W3C recommendation since 1996, two years before
> XML was published, two years before even the first draft of XPath was
> published. The latest revision of Selectors is in WD, LC, CR, or whatever
> stage we're at today, sure, but that's just the latest version -- the
> original version (which was published as part of CSS1) has been around for
> nearly a decade, is *very* widely used (far more so than XPath), and is
> very widely understood by authors.

This is the results of your research, yes? But it's all irrelevant,
Ian. There is a desire for more than one selection language, and there
is no reason not to provide it.


> > The people behind these end user applications are not Web authors, but
> > rather developers. And XBL itself is today most heavily used by Gecko
> > developers. I wish all the success in the world to XBL on the Web, but
> > we shouldn't forget that XBL is also very much geared advanced
> > development techniques and I like to think that desktop/mobile/Web
> > application developers, like me, are looking for XPath support in XBL.
>
> While it's great that technologies like HTML, CSS, and XBL are capable
> enough to be used in contexts that aren't the Web, that doesn't mean that
> those contexts should drive the specification.

You have a rather quaint view of 'the web'. There is increasingly less
and less distinction between the desktop and 'the web', and there are
many people and companies--and I would include myself here--who are
doing everything they can to remove the distinctions that remain.


> It doesn't matter if the XBL in your RSS reader's UI renderer
> interoperates with the XBL implementation in your spreadsheet package's UI
> renderer, because those are implementation-specific.

Are you sure? Is that Google-speak, or your own personal view? My goal
is almost directly the opposite of this; I want to design my own
widget that helps me enter dates, and then use that widget anywhere I
like, whether in a web-page or in some desktop application. The widget
could know about my calendar, my accessibility preferences...and so
on. You'd save me a lot time if you told me now if I shouldn't back
XBL2 if I want to achieve this!


> That has absolutely no effect on the spec which *does* have to be
> interoperable, simple, and easy to use, namely, the version of XBL which
> is to be used and deployed on the multi-UA Web.

As I said, the UA's for the desktop are converging with those for
browsing the web, so we need something that is usable in both
traditional browsers *and* other places.


> IMHO this discussion is moot. We've already had this argument many times.
> I'm not going to dance around here being politically correct, I'm just
> going to be blunt about this: I'm not happy to move forwards with an XBL2
> that uses XPath instead of Selectors, and I'm not happy to move forwards
> with an XBL2 that uses more than one binding pattern language. This design
> was reached by careful consideration based on researching what real
> authors were familiar with on the Web. Naturally not all authors will
> agree with this design, but that will always be the case.

Ah, your research again. But "real authors" who are familiar with XBL
at all, are actually familiar with XBL 1. So I suggest that you don't
add any new features, since no-one will be familiar with them. (Except
the vocal minority...)


> If you wish to raise a formal objection, I will go out of my way to make
> sure the director is aware of your position when we move to CR.

No worries...there is a mechanism for raising issues, so they will all
be taken into account anyway.


> I was asked, by the Web Application Formats working group, to bring the
> specification that I edited for Mozilla to the W3C, on the understanding
> that no major changes would be involved. I am happy to do that, and I'm
> happy to fix any real technical problems that are found in the spec.

You may not have got good advice, though...if you don't want your
document to be changed, then you shouldn't bring it to a standards
organisation that is based on discussion and listening to a broad
range of inputs.

Regards,

Mark


-- 
Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/

Received on Thursday, 3 August 2006 22:24:57 UTC