W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2002

Re: XPath DOM and XPath 2.0

From: Curt Arnold <carnold@houston.rr.com>
Date: Wed, 3 Apr 2002 10:05:04 -0600
Message-ID: <002501c1db29$51dbb5a0$a800a8c0@CurtMicron>
To: <www-dom@w3.org>
After a little more thought the existing XPathResult doesn't seem that far off.

Splitting XPathResult into XPathSingletonResult and XPathSequenceResult isn't really satisfying since it just starts a process that would be fulfilled when you had a distinct interface for XPathDoubleResult, XPathStringResult, etc.  Not necessarily a bad thing, but it should either be at one extreme or the other.

Since resultType could have values that imply no type coersion of the values, it could be compatible with explicit casts in the XPath expression, so having coersion to three or four types specifiable through the resultType isn't a restriction to just supporting those types.

The permutations for resultType start getting bad if you just try to enumerate them without any pattern.

Maybe something like:

const unsigned short ANY_TYPE = 0;
//   if none of the COERCE bits are set,
//     the type is determined by the XPath expression
const unsigned short COERCE_NUMBER = 1;  
const unsigned short COERCE_STRING = 2;
const unsigned short COERCE_BOOLEAN = 4;
const unsigned short COERCE_NODE = 8;
const unsigned short ATOMIC = 16;
const unsigned short SNAPSHOT = 32;
const unsigned short ITERATOR = 64;
//  order does not need to preserved in the result set
const unsigned short UNORDERED = 128;
//   existing constants expressed as combinations of the previous
const unsigned short NUMBER_TYPE = COERCE_NUMBER + ATOMIC;
const unsigned short STRING_TYPE = COERCE_STRING + ATOMIC;
const unsigned short BOOLEAN_TYPE = COERCE_BOOLEAN + ATOMIC;
const unsigned short UNORDERED_NODE_ITERATOR_TYPE = 
const unsigned short UNORDERED_NODE_SNAPSHOT_TYPE =
const unsigned short ORDERED_NODE_SNAPSHOT_TYPE =
const unsigned short ANY_UNORDERED_NODE_TYPE =
const unsigned short = FIRST_ORDERED_NODE_TYPE =

If you wanted to get something back in a schema datatype like date, you would just use ATOMIC and either use an explicit conversion or rely on the type of the expression.  If you wanted an array of dates, you would use SNAPSHOT or ITERATOR.

To support arrays of atomic values, you could either change the result type of iterateNext and snapshotItem to be XPathResult or you could leave the Node returning methods as convienience functions for XPathResult returning functions

//   functionally equivalent to 
//       XPathResult nextResult = iterateNext();
//       return (nextResult == null) ? null : nextResult.singleNodeValue;
Node  iterateNextNode();
//   functionally equivalent to 
//       XPathResult result = snapshotItem(index);
//       return (result == null) ? null : result.singleNodeValue;
Node  snapshotNode(unsigned long);

XPathResult iterateNext();
XPathResult snapshotItem(unsigned long);

//    a clone method for defensive copying would be helpful
XPathResult cloneResult();

For XPath 2 queries that returned other types, you would need a mechanism better than the resultType enumeration to determine the type.  Foreshadowing this with a valueTypeNamespace and valueTypeLocalName would seem reasonable.  Access methods for schema datatypes, could be relegated to a XPath2Result to be defined later.
Received on Wednesday, 3 April 2002 11:05:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:32 UTC