W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2002

Re: DOM L3 XPath: Multiple matching nodes when number, string or boolean type

From: Philippe Le Hegaret <plh@w3.org>
Date: 19 Feb 2002 18:35:45 -0500
To: Curt Arnold <carnold@houston.rr.com>
Cc: WWW DOM <www-dom@w3.org>
Message-Id: <1014161745.11965.137.camel@jfouffa>
On Sat, 2002-02-16 at 19:41, Curt Arnold wrote:
> a) Following the pattern of number() and string() in XPath and
> return the first matching value.
> b) Throw an exception, though it should be distinct from TYPE_ERR.
> c) Separate multiplicity and ordering from the return type parameter
> and have doubleValue, booleanValue, stringValue (and nodeValue for
> node snapshots?) return array types.
> d) Separate multiplicity and ordering from the return type and have
> doubleValue, booleanValue, and stringValue have an index parameter.

If we have the choice, I would pikc the compatiblity with XPath 1.0 and
wait for the XPath folks to define something better before adding it our
module. I don't think it is the role of our API to extend XPath

> Specifically, what should happen if you do:
> XPathResult result = ((XPathEvaluator)
doc,null, NUMBER_TYPE, null);

as specified in the draft, "the result will be coerced to return the
specified type relying on XPath conversions and fail if the desired
coercion is not possible.". So you'll convert into a number as defined

I guess adding a link from the constant NUMBER_TYPE to the function
number could help.

> However, I don't believe the scenario is adequately addressed in
> the current draft.  My initial leaning would be toward option c,
> however I would assume that array types are avoided intentionally
> in the DOM.

I don't remember discussions on array types in the group but that might
have happened before 1999. Anyway, I don't think we should diverge from
the XPath specification.

Received on Tuesday, 19 February 2002 18:35:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:09 UTC