[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [provision] XPath expressions.
Sorry; I chose a poor example. To stay with the examples of supportedSchemaEntities in the spec draft, I'd have said: "//Person" selects all Person instances on the target "/Person" selects all Person instances with the target as direct parent "//Group" selects all Group instances on the target "/Group" selects all Group instances with the target as direct parent Darran Rolls wrote: > Gary > > Can you elaborate on the use of "user", is this tied only to a > specific type (so to speak) or does this just mean "all the schema > object instances on the target"?. If the latter, would "//object" be > better? > > Darran > > Gary P Cole wrote: > >> 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? >> >> To unsubscribe from this mailing list (and be removed from the roster >> of the OASIS TC), go to >> http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgroup.php. >> >> > > > To unsubscribe from this mailing list (and be removed from the roster > of the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgroup.php. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]