RE: XSL Pattern Queries (values & filters) with DOM

[inline]
>
> > Why wait for XQL when we already have an incredibly powerful addressing
> > language in place - XPath 1.0.
>
> Just to be pedantically correct ;~) "XQL" generally means the proposal put
> forth by several companies in 1997 in a W3C Note; this basic
> syntax was used
> in XPath and XSL Patterns, with some modifications.  The eventual
> product of
> the W3C XML Query Language Working Group doesn't have a name yet,
> but "XQL"
> will probably *not* be it. It is likely to somehow incorporate XPath, but
> have considerably more power.
>

Yes, I agree that term XQL has become overloaded because of its history. I
was using it to refer to the work of the XML Query Language WG and not the
original notes. I wasn't aware that they weren't planning to use XQL to
refer to their work. Any idea why?

> I happen to agree that XPath would be a useful basis for a couple of DOM
> Level 3 Core methods, e.g. NodeList getElementsByXPath(DOMString
> xpathExpression) and a NodeIterator and TreeIterator constructor
> that takes
> an XPath expression.  This idea had just about ZERO support last
> summer when
> the basic Level 3 agenda was discussed, so if you care about this you'll
> have to lobby hard for it.
>

It's surprising that it would receive such little support. What is the
reasoning?

FWIW, I believe the API should be more general than something like
getElementsByXPath, because 1) XPath expressions return node-sets, which may
contain other node types than Element, and 2) it should be able to take
other addressing expressions (for future extensibility).

I'll start my lobbying...  ;)

-aaron

Received on Saturday, 15 April 2000 19:09:11 UTC