- From: Karl Dubost <karl@w3.org>
- Date: Tue, 10 Oct 2006 16:28:42 +0900
- To: Ian Hickson <ian@hixie.ch>
- Cc: public-appformats@w3.org
Le 06-10-06 à 09:05, Ian Hickson a écrit : > On Thu, 5 Oct 2006 karl@w3.org wrote: >> >> The specification defines a MUST requirement for parsing the >> document. > > The statement in question is: > > # The element attribute of the binding element and the includes > attribute > # of the content element, if specified, must be parsed according to > the > # rules in the Selectors specification. [SELECTORS] > > The requirement is not a requirement on how to parse the document, > merely > a requirement on how to parse the values of two specific attributes. yes that was understood. It was meant to be that way. Thanks for the clarification on the comment. > Those > attributes are defined as containing Selectors, so it seems wise to > require that they be parsed according to the rules of the Selectors > specification. yes. Cf another comment about "CSS Selectors", where in your reply, it is stated that Selectors is a transversal technology not related to CSS 3. That will have to be addressed at a higher level. The rest of this issue is on hold once there will be more clarifications on the outcome of WGs working on similar things. Diversity is good if there is a common model which guarantee interoperability. It is then unrelated to this thread. Thanks Ian for taking the time to answer >> It makes then impossible for a conformant parser to use XPath (or any >> kind of parsing method like regex) to parse the document. > > Any parsing mechanism can be used to parse documents containing > XBL, the > requirement quoted above is merely requiring that whatever parsing > mechanism is used, it implement the semantics of the Selectors > language > for the purposes of the two attributes mentioned. > > > >> Many XML tools have already implemented XPath and it doesn't seem >> there >> are a lot implementing Selectors. It would be better to not have a >> MUST >> on this requirement. Does it bring any benefits to impose the parsing >> rules? > > Hopfully this has clarified the confusion and removed the > misunderstanding > that any particular parsing mechanism must be used. (The parsing > _rules_ > must be defined, obviously, so that interoperability can be obtained. > However that is separate from what technology is used to implement the > parsing -- be it Perl Regular Expressions, LEX, expat, or whatever.) > > >> Selectors is also still a Working Draft. It means the XBL 2.0 >> specification will not be able to reach Rec until Selectors have >> itself >> reached PR. > > Selectors will reach PR far, far before XBL reaches PR. (Selectors has > been in CR for several years and is ready to go to PR, it is merely > awaiting the final writing of its implementation report. XBL2 > doesn't even > have a test suite yet.) > > > Please let me know if this removes your objection. > > Cheers, > -- > Ian Hickson U+1047E ) > \._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _ > \ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'-- > (,_..'`-.;.' -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool ***
Received on Tuesday, 10 October 2006 07:29:01 UTC