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 [EMAIL PROTECTED] 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).
Dean
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.
