- From: Scott Boag/CAM/Lotus <Scott_Boag@lotus.com>
- Date: Fri, 12 May 2000 18:57:56 -0400
- To: www-dom-xpath@w3.org
jeroen@tcf.nl wrote:
> If you split up PAX in a PAX core and expression specific interfaces you
can use
> the same mechanisme where an implementation can be DOM-PAX compliant if
it has
> implemented f.i. the pax-core and the pax-xpath interfaces. (or pax-core
and
> pax-inquirer patterns.. ).
Hmm.. OK, I think. What would be in PAX-core? Sorry if I'm being dense.
I'm not familiar with the details of the DOM complience stuff... I guess I
should do some studying. To me, there is only core and optional.
>> ExpressionFactory efactory = ExpressionFactory.newInstance("Xpath");
...
> compare it to:
> XPathExpression aExpression = PAXFactory.createXPathExpression();
> or
> InquirerExpression aExpression = PAXFactory.createInquirerExpression
();
In yours, you have to have exposure to a specific interface for
XPathExpression. In mine, the interface is obtained at runtime, based on a
property registration mechanism, and the interface is abstract.
> It sounds more DOMmish in my point of view, and I think it's easier to
make it
> language independent.
Not sure what more DOMmish means. Why is it more language independent? Do
you mean, Java vs. COM language independent? Why?
> I still think so but you might call it something like
"ValidateExpression".
> The purpose was not to precompile stuff separately but to validate the
> expression separately without executing it.
Can you give a use case?
-scott
Received on Friday, 12 May 2000 18:57:36 UTC