W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2002

Re: Level 3 XPath doesn't feel right

From: Shelby Moore <shelby@coolpage.com>
Date: Mon, 16 Dec 2002 13:59:55 -0600
Message-Id: <4.1.20021216134219.0155cae0(null)>
To: Ray Whitmer <rayw@netscape.com>
Cc: www-dom@w3.org

It is not a critical issue to me either way, and in my mind we are not
"arguing" :)

This friendly exchange is IMO to hash out a fundamental design issue.  I am
probably wrong in the end (given your experience in W3C), but I will
present my thoughts for sake of advancing the art...

>Yes.  Multiple implementations, from different sources is expected to be 

If we can not count on virtual class methods, then our OO arsenal is
significantly weakened.

>>I just realized the two api models are NOT mutually exclusive.  The
>>"getInterface" can merely expose the XPathEvaluator as an OO wrapper in the
>>DOM node.  And per above, I think it only needs to be implemented in once
>>place-- the base class.
>This would only be true if we expected a single implementation only ever 
>supplied by the supplier of the DOM implementation.  If we believed this 
>were true, I would not be arguing with you in the first place.
>This is not even true in the current Mozilla implementation, where it 
>may be loaded from a separate shared library.

My understanding is it is possible to implement virtual class methods in
shared libraries in efficient manner.

Some thought has to be given to designing an OO application across shared
libraries.  Because it is possible to poorly design something, does that
mean we should forsake virtual methods in W3C?

>  It would be far more 
>difficult to permit each node to be cast to an evaluator than to get the 
>Document object castable.

Why if you have a virtual method for each extension in the extended
interface returned by "getInterface"?

>Now, the logical extension, someone, in a shared library, wants to 
>supply a different implementation that they will build XML-Foo on top 
>of, that needs a set of functions applicable to foo.

I do not understand.

>Now, we have two versions of the implementation floating around. 
> sometimes users should get one, and sometimes the other.  It is quite 
>obvious that the Foo implementation is for special-use, but should be 
>able to use the same API.  Now, each node needs to be able to be cast in 
>two different ways?  It is far easier for the Foo implementer to just 
>get a FooXPathEvaluator and use it throughout his operations.

Why 2 different interfaces?  The interface is W3C standard, then the
implementation of the virtual method can vay.

>There are much more complicated scenarios than that that arise easily 
>and are easily handles with a seperate evaluator that can be obtained 
>from anywhere, that are extremely difficult if you require a node-level 
>evaluator interface.

Could you kindly explain just one important one to me if ever you have
time, because I do not visualize it (yet)?

-Shelby Moore
Received on Monday, 16 December 2002 14:59:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:10 UTC