----- Original Message ----- From: "Elliotte Rusty Harold" <[EMAIL PROTECTED]> > At 3:35 AM +0000 3/21/02, James Strachan wrote: > >After looking at XPath 2.0 which introduces XSD types, maybe we should > >return java.lang.Number again? > > > > No, XPath 2.0 is huge, not done anytime soon, and from Jaxen's > perspective a major change. Do not expect that you'll be able to make > a few changes here and there and have Jaxen work with XPath 2.0. > You're going to need to redesign most of the API. I would pay > absolutely no attention to XPath 2.0 for the time being. Focus on > making a complete 1.0 implementation which is useful in and of > itself. In fact, for Java developers I think XPath 1.0 is a much > better fit than XPath 2.0. The complications in XPath 2.0 are mostly > due to the needs of XQuery and XSLT 2.0. There are a few nice > features for Java programs (the ability to specify the default > namespace for use in XPath expressions would be convenient) but > nothing we can't live without.
Thanks for that Elliotte. You're totally right (as usual ;-). I was being a bit premature expecting us to keep similar APIs with XPath 1.0 and XPath 2.0. I read much more about XPath 2.0 after sending the previous mail and its kinda disappointing; XPath 2.0 is way too complex now, its practically XQuery already. Like you I think XPath 1.0 is just about right for our needs; I'm not actually sure if I'd want the extra complexity of XPath 2.0 any time soon. Especially when programmatically working with XPath 1.0 and a DOM-ish object model; when XPath can't do what you need you can still write real Java code. > Later you may want to design a separate XPath 2.0 API, but it won't > be at all the same thing. For example, in the case at hand, XPath 2.0 > has no number type as such. Thus there should not be a numberValueOf > method. Instead there are separate and related decimal, double, > float, int, byte, short, long, Integer, nonNegativeInteger, > nonPositiveInteger, positiveInteger, negativeInteger, and probably a > few others I've forgotten. <OT:aside> Mapping XSD types to Java types is less obvious than people may think. When I was working on the XSD data type support on dom4j I used the xsdlib from Kohsuke Kawaguchi at Sun, which is usually part of the excellent MSV distribution. So you can extract the 'primitive type' value from an Element or Attribute using the XSD type (as well as performing type-specific validation). The XSD types actually map kinda badly to Java types (and most programming languages) as they are often a bit too big. e.g. the dates have a locale attached in XSD so they don't map to a java.util.Date, they must map to a Calendar. Its a shame that there's not a standard set of XSD types that map onto those common SQL datatypes that have well defined mappings to all programming languages and would allow easy round tripping from XML <-> SQL <-> Java without loss of information. Anyways... </OT:aside> > There are much more serious differences too. The most important is > probably that the whole model is based on sequences rather than the > four fundamental XPath 1.0 types. Sequences can contain nodes or > primitive types, and as you noticed the types are not the same in > XPath 2.0. Sequences are ordered and can contain duplicates. Whereas > an XPath 1.0 expression might return a node-set, an XPath 2.0 > expression might return a sequence containing both nodes and > non-nodes. I just don't think you're going to be able to reconcile > an XPath 1.0 API with an XPath 2.0 API. Though its interesting that mostly Jaxen's API returns a List and the functions work on a List of arguments and the context is often a List etc. So Jaxen is kinda built around the sequence idea already - though I agree that XPath 2.0 is very different - but maybe the sequence change in XPath 2.0 might not make a huge difference to Jaxen. James _______________________________________________ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest
