W3C home > Mailing lists > Public > www-dom-xpath@w3.org > May 2000

Re: [dom-xpath] Competing Proposals Proposal

From: Scott Boag/CAM/Lotus <Scott_Boag@lotus.com>
Date: Thu, 11 May 2000 23:51:46 -0400
To: www-dom-xpath@w3.org
Message-ID: <OFA6DAD71D.447E4CDB-ON852568DD.0011B814@lotus.com>

jeroen@tcf.nl wrote:
> mmmmmm, expression language independence sounds good but I rather see it
> happening through add-ons with a hasFeature test.

I'm not real strong on this, though I might be an advocate of this for a
while longer.  I would be interested of other's think expression language
independence is a good thing.

> Tomorrow there will be some new query language called SSQL (super simple
> language) with a complete different expression language without the need
for an
> environment of context at all.

No.  The document should be specific that this is a query language for
XML/DOM Trees.  Certain concepts, such as the context, belong abstractly to
any expression that queries trees.

I'm not sure what we buy by being very language specific.  In particular,
I'm looking for the possibility that XQuery will be either a superset of
XPath, or may be a completely different language (I don't think anyone
knows for sure at this point).  Then there is existing non-W3C languages,
such as XQL.

On the other hand, it should certainly be tuned towards the needs of XPath.

> XObject evaluate(Node context, XEnvironment environment)
> gives an indirect dependence of specific expression languages.

I see your point, but I don't agree.  This is fairly abstract for an
XML/DOM expression language.

> I would prefer createXPathInstance() and createXSLPatternInstance()...

I think a probably agree about seperation of the select pattern vs. the
match pattern.  But the actual names depends on the outcome of the above

> add the
>  boolean  hasFeature(in DOMString feature, in DOMString version);


> The XObject interface suggests an expression independent setup thought
> constants defined point directly towards XPath.
>(and ofcourse I'm in favor of XPathResultObject.....)

As I said, the API is still tuned towards XPath.  But the constants are
pretty generic, and we could and probably should add the set of datatypes
that correspond to the Schema type set.

> Implementing a specific expression language binding should be optional,
with at
> least 1 of the available expression languages.
> compare it to DOM which might offer XSL besides CSS.

I believe CSS is optional... i.e. the core DOM only consists of basically
DOM1.  Can someone on the DOM WG confirm this?  I don't think a DOM
implementor should be required to implement any expression language.   (or
I might be misunderstanding what you are saying...)

> I don't see why this should be in the result interfaces. Sure XPath has
> rules for comparing strings with numbers etc but the interpretation of a
> site might be left to the user.

I suspect you're right.  Is anyone an advocate for leaving them in?

> By the way, am I missing something ...
> Where is the actual unparsed query set ?
> The ExpressionFactory is delivering an empty language specific instance
isn't it
> ?
> Does it mean that a specific instance has to implement the Inquirer
interface ?
> mmmmm, an explanation is welcome.

Oops, the "create" function should be:

  public abstract Expression create(String expression, PrefixResolver
    throws ParseException;

Sorry, this must have been *really* confusing!

ExpressionFactory efactory = ExpressionFactory.newInstance("Xpath");
Expression expr = efactory.create("foo/baz[yada]", myPrefixResolver);
XObject val1 = expr.evaluate(node1, myXEnvironment);
XObject val2 = expr.evaluate(node2, myXEnvironment);

or (minimalist way of doing the similar thing):

  NodeIterator iter1 = ((Inquirer)node1).selectNodes("foo/baz[yada]");;
  NodeIterator iter1 = ((Inquirer)node2).selectNodes("foo/baz[yada]");;
catch(ClassCastException cce)
  System.out.println("Inquirer not supported!");

Either way is great depending on what needs to be done!

> Additional features:
> A separate
> Expression.parseExpression() DOMException PARSE_EXCEPTION
> might be usefull.

Given create(String expression, PrefixResolver prefixResolver), do you
really think so?

Do you think more needs to be put on the Inquirer interface, like

boolean getBool(String queryString);
boolean getMatch(String queryString);

??  It's supposed to be minimal though, so maybe not.  Dunno.

Received on Thursday, 11 May 2000 23:51:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:43:07 UTC