Re: [dom-xpath] Competing Proposals Proposal

Hi Scott,

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


>Goals

>Layered
+1

>Complete 
+1

>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.

+1

>          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.
+1


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

>           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 
+1

>      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()...
DOMException INSTANTIATION_ERROR, INSTANTIATION_NOT_ALLOWED_ERROR

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

-------------------------------------
Jeroen van Rotterdam
The Connection Factory
http://www.xhive.com
-------------------------------------

Received on Thursday, 11 May 2000 17:57:25 UTC