[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: XPath expressions.
The short-form of XPATH (and what most of us usually see) is actually the "abbreviated syntax" (http://www.w3.org/TR/xpath#path-abbrev) for a location path. Some applications call these "canonical" XPath expressions. - each step assumes the "child" axis by default - "@" is short for "attribute:" - "//" is short for "/descendant-or-self::node()/" - "." is short for self::node() - ".." is short for parent:node() The long-form of XPath (the general form) is what some call an "arbitrary XPath expression". These expressions can be arbitrarily complex and may combine any number of axes. 1) Some applications support only Canonical XPath expressions, and I think that is all that SPMLv2 should require a provider to support. Gerry Woods mentioned the burden of complexity that we impose if we require a provider to support the general form of XPath expressions. 2) I think we should treat each Target as a document root that (directly or indirectly) contains all other objects as nodes. So, for example, "/user" would select all user objects directly contained by the target. The XPath expression "//user" would select all user objects on a target, no matter which container was their parent. 3) Should we further restrict the forms of XPath expressions that an SPMLv2 provider must support?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]