OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[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]