- 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