- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Sat, 17 Mar 2007 09:13:19 -0400
- To: public-appformats@w3.org
The XBL2 Candidate was published on March 16. Many thanks to Ian Hickson the Editor and the other contributors listed in the Acknowledgments section: <http://www.w3.org/TR/2007/CR-xbl-20070316/> The document includes the following Candidate exit criteria: [[ This specification will remain at the Candidate Recommendation stage until two complete and interoperable implementations exist (and not before 1 September 2007). An implementation will only be considered if it is publicly downloadable or available through some other public point of sale mechanism, and is intended for a wide audience and could be used on a daily basis. To be "complete and interoperable", an implementation must pass every test in a comprehensive test suite of every normative requirement of this specification. ]] If you intend to do some implementation work, please do share your plans and progress on this mail list. Regards, Art Barstow --- Begin forwarded message: > Resent-From: w3c-ac-members@w3.org > From: "ext Ian B. Jacobs" <ij@w3.org> > Date: March 16, 2007 11:05:46 AM EDT > To: w3c-ac-members@w3.org > Subject: XML Binding Language (XBL) 2.0 is a Candidate > Recommendation (Call for Implementations) > Reply-To: w3c-ac-forum@w3.org > > Dear Advisory Committee Representative, > > I am pleased to announce that XML Binding Language (XBL) 2.0 is a > W3C Candidate Recommendation. > http://www.w3.org/TR/2007/CR-xbl-20070316/ > > This document is published by the Web Application Formats > Working Group: > http://www.w3.org/2006/appformats/ > > The approval and publication is in response to the following > transition request: > http://lists.w3.org/Archives/Member/chairs/2007JanMar/0080 > > There were two Formal Objections. Despite these, the Director > supports publishing the XBL2 specification as a Candidate > Recommendation; see the full discussion below. > > This specification will remain at the Candidate Recommendation > stage until two complete and interoperable implementations exist > (and not before 1 September 2007), as described in the document > status section below. There is no initial implementation report. > > For information about any patent disclosures regarding this > specification, see: > http://www.w3.org/2004/01/pp-impl/38483/status > > This Call for Implementations follows section 7.4.3 of the W3C > Process Document: > http://www.w3.org/2005/10/Process-20051014/tr#cfi > > Thank you, > > For Tim Berners-Lee, Director, > Chris Lilley, Interaction Domain Leader, and > Dean Jackson, Rich Web Client Activity Activity Lead; > Ian Jacobs, Head of W3C Communications > > ====================== > Disposition of Comments > ====================== > > The Director approves the transition of XBL2 to Candidate > Recommendation. This decision acknowledges XBL2 does not align > with some existing W3C technologies. The Director sees a > significant community behind XBL2, and believes there is value in > continuing the development of this technology within W3C. We must > provide the opportunity for multiple approaches to be developed > within the Consortium, in the way that specifications such as > CSS, XSL, XML Schema and RDF Schema were made W3C Recommendations > despite overlaps and incompatibilities. Unfortunately this means > that there were a number of comments made on XBL2 that were > rejected as being out of scope even though they were consistent > with other technologies at W3C. These comments did not go > unnoticed. We hope that many of these disagreements can be tested > and resolved with implementation experience gained during the > Candidate Recommendation phase. > > The Formal Objections" and "rejections with strong disagreement" > from the following disposition of comments were examined; see > the disposition of Last Call comments for details: > http://www.w3.org/2007/03/doc > > With regard to issue 45 concerning the need for an Internet media > type for XBL, the Director tentatively agrees that there is no > compelling need at this time, but requests that the issue be > revisited if a more concrete need for one becomes evident. > > In response to issue 86 regarding the abstract, the following > change was made during the transition teleconference and it is > hoped that this addresses the concern raised: > > http://dev.w3.org/cvsweb/2006/xbl2/Overview.html.diff? > r1=text&tr1=1.193&r2=text&tr2=1.192&f=h > > Regarding issue 87 and the ability for XBL to affect a document's > intrinsic meaning, the Director requests that the XBL community > and Doug Schepers in particular discuss eventually replacing this > text: > > "XBL cannot be used to give a document new semantics. The > meaning of a document is not changed by any bindings that are > associated with it, only its presentation and interactive > behavior." > > with this text: > > "XBL cannot be used to override the meaning of a document as > defined by the spec of the language it is written in. Any > bindings that are associated with it add information about > its presentation and interactive behavior, and these have to > be consistent with the original interpretation of the > document." > > or by a normative paragraph (not a note, replacing "have to" by > "should"): > > "XBL cannot be used to override the meaning of a document as > defined by the spec of the language it is written in. Any > bindings that are associated with it add information about > its presentation and interactive behavior, and these should > be consistent with the original interpretation of the > document." > > The Director agrees with the current intent of the specification, > however, and does not think that the paragraph should be removed; > nor does the Director think that this change should further delay > XBL2's progression to Candidate Recommendation. > > Issue 153 remains a difficult issue with two conflicting > requirements. The Director suggests that the XBL community > specifically request feedback from implementors and authors > during the CR phase, and requests that it be made clear that this > design could change pending implementation experience. > > Finally, for issues 9 and 163 regarding xml:id, the Director > supports the decision to not use xml:id, because of the position > expressed by certain browser vendors that requirements to support > xml:id would be ignored. However, the Director requests that > during the Candidate Recommendation phase that the XBL community > solicit feedback from authors and implementors on whether XBL > should rely exclusively on xml:id instead of having its own "id" > attribute. Further, the Director suggests that the XML > Coordination Group should discuss xml:id with browser vendors to > see if their reluctance can be addressed, e.g. by more clearly > defining the rules for the handling of elements with multiple > declared IDs. > > For the full list changes since Last Call, see: > http://dev.w3.org/cvsweb/2006/xbl2/ > > ============================================ > Quoting from > XML Binding Language (XBL) 2.0 > W3C Candidate Recommendation - 16 March 2007 > ============================================ > > > This Version: > http://www.w3.org/TR/2007/CR-xbl-20070316/ > Latest Version: > http://www.w3.org/TR/xbl/ > Previous Versions: > http://www.w3.org/TR/2007/WD-xbl-20070117/ > http://www.w3.org/TR/2006/WD-xbl-20060907/ > http://www.w3.org/TR/2006/WD-xbl-20060619/ > http://www.mozilla.org/projects/xbl/xbl.html > http://www.w3.org/TR/2001/NOTE-xbl-20010223/ > Editor: > Ian Hickson, Google, Inc. > > Abstract > > The XML Binding Language (XBL) describes the ability to > associate elements in a document with script, event handlers, > CSS, and more complex content models, which can be stored in > another document. This can be used to re-order and wrap > content so that, for instance, simple HTML or XHTML markup can > have complex CSS styles applied without requiring that the > markup be polluted with multiple semantically neutral div > elements. > > It can also be used to implement new DOM interfaces, and, in > conjunction with other specifications, enables arbitrary tag > sets to be implemented as widgets. For example, XBL could be > used to implement the form controls in XForms or HTML. > > Status of this document [ Non-boilerplate ] > > This is the 16 March 2007 Candidate Recommendation of XBL > 2.0. Implementations are encouraged. This specification will > remain at the Candidate Recommendation stage until two > complete and interoperable implementations exist (and not > before 1 September 2007). An implementation will only be > considered if it is publicly downloadable or available through > some other public point of sale mechanism, and is intended for > a wide audience and could be used on a daily basis. To be > "complete and interoperable", an implementation must pass > every test in a comprehensive test suite of every normative > requirement of this specification. > > Publication as a Candidate Recommendation does not imply > endorsement by the W3C Membership. At the time of publication, > there was no implementation report. A future version of this > specification, which will include fixes based on > implementation feedback, will include a link to a test suite > and an implementation report. > > If you wish to make comments regarding this document, please > send them to dev-tech-xbl@mozilla.org (subscribe, archives) or > public-appformats@w3.org (subscribe, archives). All feedback > is welcome. The editor guarantees that all feedback sent to > the above lists will receive responses before this > specification advances to the next stage of the W3C process. > > The editor's copy of this specification is available in W3C > CVS. A detailed list of changes is available from the CVS > server. > > This specification is a (non-backwards-compatible) revision of > Mozilla's XBL 1.0 language, originally developed at Netscape > in 2000, and originally implemented in the Gecko rendering > engine. [XBL10] > > This specification was developed by the Mozilla Foundation and > its contributors, in conjunction with individuals from Opera > Software ASA, Google, Inc, and Apple Computer, Inc, to address > problems found in the original language and to allow for > implementation in a broader range of Web browsers. > > This document is also based, in part, on work done in the > W3C's Bindings Task Force. However, no text from that > collaboration, other than that written by the aforementioned > contributors, remains in this specification. Inspiration was > similarly taken from other efforts, such as HTML > Components. [HTC] > > 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.) > > While the body of this specification was created outside the > W3C, the W3C Web Application Formats Working Group is now > guiding this specification along the W3C Recommendation track. > > This document was produced by a group operating under the 5 > February 2004 W3C Patent Policy. W3C maintains a public list > of any patent disclosures made in connection with the > deliverables of the group; that page also includes > instructions for disclosing a patent. An individual who has > actual knowledge of a patent which the individual believes > contains Essential Claim(s) must disclose the information in > accordance with section 6 of the W3C Patent Policy. Feedback > requests > > While feedback is welcomed on all aspects of this > specification, especially from implementors and authors using > XBL on the Web, feedback is especially requested on two > contentious issues. > > The first concerns ID attributes. This specification defines > an attribute id for uniquely identifying elements in > XBL. There exists a specification for a global xml:id > attribute, which can also be used with XBL. Feedback is > requested from implementors and authors using XBL on the Web > regarding whether XBL should instead require that authors use > the xml:id attribute, and forbid the use of the id attribute > on XBL elements. > > The second contentious issue regards an intentional > limitation: unless an element is explicitly bound to a binding > that provides access to its shadow tree or its bound element, > there is no easy way to get access to them from script running > outside the element's bindings. This is a feature that may be > introduced in a future version, but it is not clear how much > need there is for it. > > If you have any opinions or experience regarding these issues > or any others, please send them to dev-tech-xbl@mozilla.org > (subscribe, archives) or public-appformats@w3.org (subscribe, > archives). > > -- > Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs > Tel: +1 718 260-9447
Received on Saturday, 17 March 2007 13:14:31 UTC