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

Re: [dom-xpath] Competing Proposals Proposal

From: <jeroen@tcf.nl>
Date: Thu, 11 May 2000 23:57:12 +0200 (CEST)
Message-Id: <200005112157.XAA20350@webmail2.xs4all.nl>
To: www-dom-xpath@w3.org
Hi Scott,

Nice start (sorry for the late reaction)!
First quick reaction:




>Expression Language Independent 

>The PAX API need not expose the expression language directly to the interface. 
>Therefore, it will be possible to use PAX to address other expression languages 
>besides XPath, such as Perl (in a limited fashion), or perhaps
>a full-blown XML Query Language.

mmmmmm, expression language independence sounds good but I rather see it 
happening through add-ons with a hasFeature test.

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

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

>           1.The API must support all XPath functionality.


>          2.It must be DOM-compatible, i.e., use DOM concepts rather than 
invent any new infrastructure (such as Nodes,
>              lists, iterators, etc.) unless absolutely necessary.

>           3.It must be language neutral and vendor neutral.

>           5.Implementation of PAX should be optional for DOM implementors. 

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.

>      7.It should provide a way to install XPath extension functions, and 

>      10.It must support the binding of variables. The types of these variables 
will be return Node-sets, Booleans, Numbers, and Strings, but other variable 
types should be possible, such as a Java Object (which may be passed to an 
extension function).

Java Object -> Object

>  public static ExpressionFactory newInstance(String language)
>        throws java.lang.IllegalAccessException,
>        java.lang.InstantiationException,
>        java.lang.ClassNotFoundException

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

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

>public interface XObject
>    {  
>      public static final short NODESET = 1;
>      public static final short BOOLEAN = 2;
>      public static final short STRING =  3;
>      public static final short NUMBER =  4;

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

> lessThan, lessThanOrEqual etc ...

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

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.

Additional features:

A separate 
Expression.parseExpression() DOMException PARSE_EXCEPTION 
might be usefull.


I have to dig into it a bit further, especially the function extensions.

More later.


Jeroen van Rotterdam
The Connection Factory
Received on Thursday, 11 May 2000 17:57:25 UTC

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