OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: We need an XPath API



At 16:53 03/03/2001 -0500, Simon St.Laurent wrote:
>At 04:29 PM 3/3/01 -0500, Charles Reitzel wrote:
>>Proposal: let's give XPath the SAX treatment.
>>
>>What should such an API do?  How should it behave?
>
>Just for prior art, there's a Simple API for CSS.  Don't know if there'd be 
>any overlap at all, but you never know:
>http://www.xmlhack.com/read.php?item=685
>http://www.w3.org/TR/SAC/

There definitely *is* an overlap. It's not complete because XPath can do
stuff unmodified CSS selectors can't (mostly functions, plus non-element
nodes thought both of these are handled by SAC nevertheless), and CSS can
do stuff that XPath can't (pseudo-classes and pseudo-elements, plus some
matching on partial attribute values, though those could probably be ported
to XPath functions). I think the main difference is that CSS selectors work
on elements only, which brings it to define root as what XPath people would
probably call the document elements. There are some rough spots but I
haven't bumped into something that couldn't be worked around.

I think there's a need for a common selector model that could be
instantiated for CSS using SAC's {Selector,Condition}Factories, and for
XPath using some similar SAXPath thing.

-- robin b.
You can tune a piano, but you can't tuna fish.