Re: W3C Selectors

At 10:14 30/01/2001 +0100, Eric van der Vlist wrote:
>Robin Berjon wrote:
>> Mentionning that, are there any plans to somehow unify the various
>> "selecting" abstract models (XPath, Selectors, and I guess XQuery) ? I know
>> that there are differences (for instance XPath would know nothing of :hover
>> for instance) but there are also common elements. It would be nice if
>> implementors could create a selector API that could be driven likewise by
>> various syntaxes. That way you just have to plug in a parser for the
>> syntax, and voila ! you can start selecting out of a DOM tree.
>
>Reminds me of a thread on xml-dev [1]. That would definitely be a great
>thing to have, please keep us updated !
>[1] http://lists.xml.org/archives/xml-dev/200005/threads.html#00680 

I know it would be a nice thing to have, which is why I try to work on it
in my spare time :) I remember that thread, but you did a good thing
bringing it back to memory. It mentions SVG, and my company is presently
seriously involved in SVG development. So I might find a way to slip that
into real work time if I see matching requirements at some point. I really
need to get my new CSS::{Parser,SAC} module together sometime soon.

On thing I don't get in your last post to that thread
(http://lists.xml.org/archives/xml-dev/200005/msg00705.html):

"You can have things like "DIV * P", "DIV P *[href]", "DIV OL>LI P" or
'SPAN[hello="Cleveland"][goodbye="Columbus"]'.

Even transformed into XPath paths they wouldn't be useable within XSLT
transformations since XPath paths need to be constants..."

I'm not sure I understand your point about XPath paths needing to be
constants. css2xpath seems possible to me (as it seems to you), even though
one would lose some pseudo class information (they could be mapped into
functions, but that wouldn't make much sense in an XSLT context). I think
that I understand from your last sentence that one could not have an XML
representation of CSS selectors which one would select from, store into a
variable, and then use as a template match because paths in templates
cannot be variables. That's true, but you seem to imply in your post that
it's a total blocker while I think there's still potential to translating
CSS to XPath and vice versa, and in general selector languages between
themselves.

Did I understand your post or is there another fundemental blocker that I'm
missing ?

I don't know how useful it would be but one could write an extension
function called css() and use that as a selector in XSLT (eg
match='css("div > p span[test]")').

I'll look into that when I have time, I'll keep you posted if I come up
with anything interesting. Thanks for any suggestions you may have.

-- robin b.
Learn from your parents mistakes - use birth control.

Received on Wednesday, 7 February 2001 20:15:54 UTC