W3C home > Mailing lists > Public > public-appformats@w3.org > October 2006

Re: [XBL] XBL 2.0 - Selectors for parsing, and XPath?

From: Dean Jackson <dino@w3.org>
Date: Thu, 26 Oct 2006 21:31:46 +1000
Message-Id: <80B98D07-9BF5-42B1-8563-3CF26BBD9839@w3.org>
Cc: Ian Hickson <ian@hixie.ch>, public-appformats@w3.org
To: Karl Dubost <karl@w3.org>

On 10/10/2006, at 5:28 PM, Karl Dubost wrote:

> 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

Karl, does this mean you're no longer objecting? (Ian asks this  
question below).


>>> 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.
Received on Thursday, 26 October 2006 11:32:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:05 UTC