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

Re: [www-dom-xpath] <none>

From: Scott Boag/CAM/Lotus <Scott_Boag@lotus.com>
Date: Fri, 12 May 2000 18:57:56 -0400
To: www-dom-xpath@w3.org
Message-ID: <OFAA38B0BD.5C0CDE09-ON852568DD.007CFC65@lotus.com>

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
> 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
> The purpose was not to precompile stuff separately but to validate the
> expression separately without executing it.

Can you give a use case?

Received on Friday, 12 May 2000 18:57:36 UTC

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