I think that it would be better now to use XBL 2.0 in SVG than sXBL (XBL 2.0 will obviously have a more wider audience, and the differences between them should not be too important). As of now, it seems to me that only Batik implements the current state of sXBL in its codebase.

However, I think it would be interesting to provide a rough draft about the differences between the latest sXBL working draft and XBL 2.0. Anne van Kesteren already provided a synthesis of the differences in 2005 here <http://annevankesteren.nl/2005/11/xbl>.

Hervé Girod

Dean Jackson wrote:

On 10/09/2006, at 12:05 PM, Matthew Raymond wrote:


Hervé Girod wrote:
I just saw on W3C Web site that Web appformats WG has released a Last
Call Working Draft for XBL 2.0, and I have some questions about the WG
strategy about XBL 2.0 / sXBL relationship.

   From the XBL 2.0 Last Call working draft:

| Although they have had related histories, this specification is
| separate from the W3C's "sXBL" drafts, and is not compatible with
| them. (The two efforts use different namespaces, for one.)

- will the sXBL working draft be dropped in favor of the more general
XBL 2.0 (there is a specific chapter on XBL 2.0 with SVG, and it seems,
by looking at the table of contents, that the xSBL TOC is a subset of
XBL 2. TOC too) ?

   I've heard rumors that sXBL is dead. The working draft for sXBL is
over a year old. Considering that XBL 2.0 is now in Last Call, it's
probably a safe bet that the rumors are true.

There certainly isn't any activity on sXBL at the moment.
However, I don't think we can call it dead just yet. SXBL is
still a chartered work item for the SVG group. As Anne suggested,
maybe sXBL will be updated to be compatible with XBL 2.0, or just
updated in general.


- is sXBL a subset of XBL 2.0, or is there some ([voluntary]) subtle
differences between the two recomandations ?

   Originally, sXBL was supposed to be a subset of XBL 2.0 for SVG, and
XBL 2.0 would have been based on sXBL once the specification reached
maturity. I think what happened is when sXBL stalled, they went ahead
with XBL 2.0 and broke compatibility with sXBL as it became increasingly
outdated.

The XBL 2.0 that is currently in last call broke compatibility
with sXBL in its first draft - it wasn't something that happened
over time. Now that XBL 2.0 is a more mature specification than
sXBL it will be interesting to see what path sXBL takes if it is
published again. I don't think the world wants two binding
specifications, but there might be some things in XBL 2.0 that
make it unacceptable for standalone SVG implementations (for
example).

Dean





Reply via email to