Re: XPath and find/findAll methods

Yehuda Katz
(ph) 718.877.1325


On Wed, Nov 23, 2011 at 9:01 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Wed, Nov 23, 2011 at 8:31 AM, João Eiras <joaoe@opera.com> wrote:
> > You're making a choice for the developers. If developers want to use
> xpath,
> > they should, it's their choice. Actually, they can, but the current DOM 3
> > XPath API is extremely convoluted..
> >
> > The whole thing about patronizing developers about having to learn
> another
> > technology is also not valid, besides being easily confused with
> > intellectual arrogance. It's their choice again, and XPath is fairly
> simple.
>
> Yes, we make choices for developers all the time.  That's called
> "being a responsible spec author".  Keeping the platform
> simultaneously as simple and as powerful as possible is challenging,
> but it's our mandate.  Offering every possible functionality *sounds*
> nice until you actually experience it; then it's called "bloat".
>

At the risk of being laughed off the mat for quoting Matz (the creator of
Ruby), I'm going to do it anyway:

*Bill Venners:* Dave Thomas also claimed that if I ask you to add a feature
> that is orthogonal, you won't do it. What you want is something that's
> harmonious. What does that mean?
>


> *Yukihiro Matsumoto:* I believe consistency and orthogonality are tools
> of design, not the primary goal in design.
> *Bill Venners:* What does orthogonality mean in this context?
>


> *Yukihiro Matsumoto:* An example of orthogonality is allowing any
> combination of small features or syntax. For example, C++ supports both
> default parameter values for functions and overloading of function names
> based on parameters. Both are good features to have in a language, but
> because they are orthogonal, you can apply both at the same time. The
> compiler knows how to apply both at the same time. If it's ambiguous, the
> compiler will flag an error. But if I look at the code, I need to apply the
> rule with my brain too. I need to guess how the compiler works. If I'm
> right, and I'm smart enough, it's no problem. But if I'm not smart enough,
> and I'm really not, it causes confusion. The result will be unexpected for
> an ordinary person. This is an example of how orthogonality is bad.
>


> *Bill Venners:* In other words, the orthogonal features will work once
> the compiler writer understands them and gets them to work. But it is hard
> for programmers to understand it when they look at it, because it is
> complicated, because I have to figure out how these two things go together.
>


> *Yukihiro Matsumoto:* The orthogonal features, when combined, can explode
> into complexity.
>


> *Bill Venners:* So what's the alternative? What would be more harmonious?
>


> *Yukihiro Matsumoto:* *Just pick up one of those two to put into the
> language. You don't have to do everything that you can think of. You need
> to pick one of them, even though both are good.*





>
>
> > XPath is already perfectly defined, supported, and implemented in many
> user
> > agents. It's not just a bunch of wild ideas on how to make Selectors work
> > with parents (which will never be accepted by the css working group), or
> > support nested Selectors. If someone actually defined a second dialect
> for
> > selectors, one for CSS and the other for the DOM API, then lots of effort
> > would be wasted reinventing another selection syntax, still more limited
> > than XPath.
> >
> > Claiming that using Selectors plus DOM traversal is a solution is like
> > saying iframes are a good alternative to XHR. Any use of DOM traversal is
> > verbose and will be preferably avoided, and causes temporary objects to
> be
> > created just to be gc'ed afterwards. But because Selectors don't do many
> > useful things XPath does, the developer will either be frustrated,
> having to
> > workaround the limitations of the API, use a selection library that has
> the
> > features need, or wrap the current XPath API.
> >
> > Lastly, the only thing that is needed is a specification perhaps the size
> > (or even smaller) than the Selectors API specification to define an API
> that
> > interprets XPath. There's no need for extra syntax sugar, nor to specify
> > algorithms.
>
> The problem, as Aryeh said, is that *almost all* of XPath can already
> be done easily done with a combination of Selectors and JS (and adding
> findAll and NodeArray will make the two combine together much more
> neatly).  We can pull functionality that's still missing into either
> Selectors or JS, but there's not too much.  For example, XPath's
> axises seem pretty useful, and it would be very easy to expose that
> functionality from JS, to quickly retrieve all the elements on a
> particular axis.  Adding a few small extensions to the existing two
> technologies is better then adding a third technology.
>
> ~TJ
>
>