Community
Participate
Working Groups
The XPath2 API and standard implementation classes need a makeover. The primary concerns are the following: - Have a real API for types - Support proper "customizable" function libraries - Support proper/decoupled tifecycles for dynamic and static contexts - ResultSequence API kills performance - Separate into a builder and an read-only part - Provide a simple XPath facade which resembles the XPath1 API and makes simple "single use" scenarios easy. Finally, we'll want to provide other PSVI type providers than Xerces (notably WTP, possibly also Xalan). I already have a patch for that.
Moving to the XPath component out of XSL.
- More items to consider: Better support for user-specified functions and types - Use normal Java identifier conventions - Provide precise API-evolvability information for better API tooling - Remove the need for accessing internal packages I will upload the first shot at a proper API tomorrow, Wednesday.
Created attachment 188643 [details] First draft of an API bundle I'm not totally finished with the top level parts of the interface, but it so far, I've removed the problems of the current API (as explained in this bug) There are a few issues left: - no facade API implementation classes yet - hence no access to function libraries - similarly, no access to built-in types yet - No ResultSequence factory yet, either - I want to split out a DOMFactory or something so that a caller may effectively use their own DOM-like structure (DTM, perhaps?) without having to mimic a full L3 DOM. - likewise, no support - TypeDefinition interfaces need cleaning up - I'm not keen on having the value "owning" their operations (plus, minus, etc.) when the spec sees these operations as function calls with a pretty scecific promotion rules -- but it's too big a change and besides, it can be changed internaly without letting the interfaces change. Comments are wildy appreciated.
I have now begun the process of porting the processor to the new API, as a version 2.0 of the processor. Four questions linger: - Are we really OK with breaking binary compatibility for 2.0? - Also, is it silly to put the XPath2 API into a bundle of its own? - If we code this against a JRE level of 1.4.2, is that "good enough" for Xerces, or are you still planning to backport the Schema 1.1 part to Java 1.3? - Also, even if we build this against 1.4.2, we will still be running the Eclipse.org hosted CI tests against 1.5 (I think, or perhaps 1.6). Can Mukul or the Xerces project somehow help out in testing against 1.4.2?
A Major version increase means backwards compatibility is not guaranteed. If you want to leave the old API in place, then you should deprecate it, and make sure it under the covers uses the new API. We will then remove deprecated API in three revisions (which is what I think the eclipse platform is using.) Regardless if we deprecate something we need to say what should be used in it's place. The unit tests on the CI machine run with Java 1.6.
(In reply to comment #5) > A Major version increase means backwards compatibility is not guaranteed. If > you want to leave the old API in place, then you should deprecate it, and make > sure it under the covers uses the new API. Right. The question is whether or not we want to do this... I'm voting for ripping out the old API as it was not really well conceived to begin with, and it appears that only Xerces-J is using it, and they are willing to move to the new API for their 2.12 version. And, thanks for clarifying!
I'm for ripping it out and just using the new. We'll need to update the New Help for Old Friends pages on the wiki to explain the reasons why things were done. Or what has changed.
Hi Jesper, I'll try to look at the new API draft posted by you asap, and would respond back at earliest with comments if any. (In reply to comment #4) > - If we code this against a JRE level of 1.4.2, is that "good enough" for > Xerces, or are you still planning to backport the Schema 1.1 part to Java 1.3? As far as I'm aware, Xerces has plans to remain at min JRE level of 1.4 (therefore level 1.4.2 should be ok for Xerces). I don't think Xerces has plans to backport schema 1.1 implementation to 1.3. > - Also, even if we build this against 1.4.2, we will still be running the > Eclipse.org hosted CI tests against 1.5 (I think, or perhaps 1.6). Can Mukul or > the Xerces project somehow help out in testing against 1.4.2? I think currently PsychoPath XPath2 tests (hosted at eclipse.org) are at JDK level 1.5, and that's common for the psychopath code-base HEAD location (using JDK level 1.5) and the service branch (using JDK level 1.4). Ideally I would wish to retain this configuration, since porting PsychoPath tests to level 1.4 looks like a significant effort and I don't seem to forsee big gains from this effort. If you think you need support from Xerces side to test new PsychoPath API design, I'll be pleased to offer needed assistance. Regards, Mukul
As I'm implementing this, there's one piece of API I'm having serious doubts about, still. I'm keeping "old way" of having rich datatypes around, like XSUnsignedInteger, only they're API now and thus interfaces. But under the hood, it could just as well just be a type tag and an java.util.BigInteger. basically we have (abbreviated) // alternative 1 interface ResultSequence { int size(); AnyType item(int index); } and AnyType has a getTypeDefinition() method on it. The specific subinterfaces of AnyType contains typed getters (e.g. getBooleanValue() - useful when you statically know the XPath expression), but AnyType itself contains a getValue() which returns an Object (useful if you are making something which uses the XPath dyamically, like e.g. a BPEL processor). But shouldn't that be // alternative 2 interface ResultSequence { int size(); Object item(int index); ItemTypeDefinition getType(int index); } The XPath type mapping would be available at runtime. The pros would be that we aren't forcing the implementation to instantiate a lot of unneeded wrappers, e.g. if we implement type checks and make a byte-code compiler under the hood, but the cons would be that we would lose the nice wrappers (especially the date/type/duration classes) // alternative 3 interface ResultSequence { int size(); AnyType item(int index); Object nativeItem(int index); ItemTypeDefinition getType(int index); } This option makes ResultSequence more verbose, but allows the underlying implementation to choose it's underlying method. What should it be - 1, 2 or 3?
I would refer and try to conform to what the XPath Data Model says to do in these cases: http://www.w3.org/TR/xpath-datamodel/ Particularly the section on Accessors.
(In reply to comment #10) > I would refer and try to conform to what the XPath Data Model says to do in > these cases: > > http://www.w3.org/TR/xpath-datamodel/ > > Particularly the section on Accessors. Thanks for the pointer. I think we are OK for the datamodel access to the nodes (handled in NodeType), it's the builtin types I'm worried about, mainly for Java clients' access to it. Let's say you have an XPath2 expression which you know will evaluate into an xs:int, stores in "myRS". How do you get this result out? Alternative 1 would be: ((XSInt)myRS.item(0)).getIntValue() Alternative 2: ((Integer)myRS.item(0)).intValue() Alternative three would leave this choice to client. Perhaps there's a nicer, safer variant in "myRS.typedItem(0, Integer.class).intValue()" Then there's the access to fields in the builtin types. The DM document doesn't deal with this, either, example: There's no dm:year equivalent for gYearMonth. In XPath2, there is a fn:year-from-date, but what this boils down to is this: How to write Java which gets the year of some gregorian date which you (staticcally know you have) stored in a resultset? Alternative 1: ((YearOp)myRS.item(0)).getYear() In an alternative 2 world, we would be constrained into: ((Calendar)rs.item(0)).get(Calendar.YEAR) Again, alternative 3 would give you the choice between the two above. Alternatively, we could expose the accessors as (XPath2) functions instead: FnYearFromDate.evaluate(myRS).typedItem(0, Integer.class)).intValue() Oh, I don't know! I haven't had complaints over the JAR's size, so perhaps alternative 3 the the safest one at this point. The old XPath1 API reminds me most of alternative 4 in a way, but is not really comparable. Mukul, do you have any preferences in this question? I guess this is as much a question of instinct and taste as it is of engineering - this is beyond the scope of the involved specs.
I believe a lot of what you are looking for is documented in the JSR 225 which covers the XQ for Java API set. It covers items like getting items from ResultSequences. I'll attach the final spec here.
Created attachment 190215 [details] XQJ spec.
(In reply to comment #12) > I believe a lot of what you are looking for is documented in the JSR 225 which > covers the XQ for Java API set. It covers items like getting items from > ResultSequences. Facepalm! I remember you pointing me in this direction once before, but I didn't quite "get" it back then, I guess I was too perplexed by its closeness to JDBC. The big question is how to get the QXJ API into Eclipse. If it's not already used in XQDT, I don't see this happening for Indigo. Also, the API is really not too clever, I defer to Michael Kay's musings on the subject. http://saxonica.blogharbor.com/blog/_archives/2007/11/21/3367880.html
(In reply to comment #14) > (In reply to comment #12) > > I believe a lot of what you are looking for is documented in the JSR 225 which > > covers the XQ for Java API set. It covers items like getting items from > > ResultSequences. > > Facepalm! > > I remember you pointing me in this direction once before, but I didn't quite > "get" it back then, I guess I was too perplexed by its closeness to JDBC. > > The big question is how to get the QXJ API into Eclipse. If it's not already > used in XQDT, I don't see this happening for Indigo. > > Also, the API is really not too clever, I defer to Michael Kay's musings on the > subject. http://saxonica.blogharbor.com/blog/_archives/2007/11/21/3367880.html What I'm thinking is designing our API to take what makes sense from that API at an interface level, but not necessarily trying to implement the full JSR 225. Particularly focus on how ResultSequences and Items are handled in the first iteration. We can then expand on this as we work on 2.1 BTW, 3.3M6 cut off is next week. So if you can get the initial API put in, we can then continue working on it in 3.3M7 to refine it.
(In reply to comment #15) > What I'm thinking is designing our API to take what makes sense from that API > at an interface level, but not necessarily trying to implement the full JSR > 225. Particularly focus on how ResultSequences and Items are handled in the > first iteration. We can then expand on this as we work on 2.1 > > BTW, 3.3M6 cut off is next week. So if you can get the initial API put in, we > can then continue working on it in 3.3M7 to refine it. I will. I was intending to add it into a shorter package, such as org.eclipse.wst.xml.xpath2.api - also to show the clean break from the previous stuff - so should that be in a separate bundle, or do you think it'll be ok inside the org.eclipse.wst.xml.xpath2.processor?
Created attachment 190316 [details] JSR 225 source and classes It's probably too late to get CQs approved in time for 3.3 release, but I'm attaching the source and jars for JSR 225 to the bug. Of most interest to us are the XQItemAccessor, XQItem, XQSequence, XQResultSequence, and XQResultItem interfaces. At least they should provide an idea of what to do from an XPath standpoint. We can look at doing an JSR 225 implementation at a future date as well. Like Michael Kay in our main implementation, connection means nothing to us, but it might mean something for Adopters that build on top of PsychoPath.
(In reply to comment #16) > > I will. I was intending to add it into a shorter package, such as > org.eclipse.wst.xml.xpath2.api - also to show the clean break from the previous > stuff - so should that be in a separate bundle, or do you think it'll be ok > inside the org.eclipse.wst.xml.xpath2.processor? I'm fine with putting it in the org.eclipse.wst.xml.xpath2.api package within the org.eclipse.wst.xml.xpath2.processor bundle.
API committed, but not tagged yet, version bumped to 2.0.
Hi Jesper, (In reply to comment #19) > API committed, but not tagged yet, version bumped to 2.0. just took an update of PsychoPath HEAD location and attempted compile with JDK 1.5. In class org.eclipse.wst.xml.xpath2.api.DynamicContext you do an import import com.sun.xml.internal.txw2.Document which gives me a compilation error (the import cannot be resolved) Can't we do, import org.w3c.dom.Document; Regards, Mukul
(In reply to comment #11) > Mukul, do you have any preferences in this question? none at the moment... Regards, Mukul
I'm moving this question to this bug report (copied from bug 338999), "I'm noticing that the test project is updated to use new APIs. It now seems that the test project cannot test service branch at the moment (we should be able to test the service branch too). What should we do regarding this?" here are few more thoughts related to this, Perhaps we could somehow refactor the test project and invoke it via a parameter (or system property), so it works in HEAD testing mode or testing the service branch. i'm currently leaving this question open to discussion. my assumption is that the service branch will use the old APIs (in parallel to the new API effort on the HEAD), so old adopters like Xerces can take it's benefit. Is this correct? Overtime Xerces may change to new APIs; i'm assuming using the PsychoPath build from the service branch, but service branch has to remain at JDK 1.4 level for Xerces to use it. i'll spend some effort later to test Xerces with new APIs, when i've completely understood the newer APIs.
(In reply to comment #22) > I'm moving this question to this bug report (copied from bug 338999), > > "I'm noticing that the test project is updated to use new APIs. It now seems > that the test project cannot test service branch at the moment (we should be > able to test the service branch too). What should we do regarding this?" > > here are few more thoughts related to this, > > Perhaps we could somehow refactor the test project and invoke it via a > parameter (or system property), so it works in HEAD testing mode or testing the > service branch. i'm currently leaving this question open to discussion. > > my assumption is that the service branch will use the old APIs (in parallel to > the new API effort on the HEAD), so old adopters like Xerces can take it's > benefit. Is this correct? You will need to check out the version of the tests from the old branch. The current head branch will migrate to he new APIs for the tests. > > Overtime Xerces may change to new APIs; i'm assuming using the PsychoPath build > from the service branch, but service branch has to remain at JDK 1.4 level for > Xerces to use it. i'll spend some effort later to test Xerces with new APIs, > when i've completely understood the newer APIs. See above.
Resolving this as FIXED as this was added in the new API. I will open a few adjustments that would be safe to put into M7.
