Re: [provision] XPath expressions.

[Gary P Cole <Gary.P.Cole@Sun.COM>]

Participants in today's conference call agreed that SPMLv2 should 
*require* a provider to support only the abbreviated syntax for XPath 
expressions. Naturally, any provider is free to support richer set of 
XPath expression forms. 

Rami suggested that we add a new value of 
ErrorCode#unsupportedSelectionType (roughly analogous to 
unsupportedIdentifierType) to use when the SelectType#path is too 
complex or when the provider does not support the expression language 
that SelectType#namespaceURI specifies.   I'll add this to 
draft_13_xsd_issues.txt.

The challenge is now to find the right words. How about the following?

    A provider MUST support the abbreviated syntax for XPath expressions.
    Put differently, a provider MUST support any XPath location path
    that does not include an explicit axis specifier.

    An XPath expression that uses only the abbreviated syntax
    contains no explicit axis specifier:
    - 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()

    A provider MUST treat each Target as a document root that
    (directly or indirectly) contains all other objects as nodes. 
    So, for example,
    - "/Person" would select every Person object
       that the target directly contains. 
    - "//Person" would select every Person object on a target,
        no matter which container was the Person object's parent.

    A provider MAY support explicitly specified axes. 
    A provider MAY support arbitrary XPath expressions.
    However, a requestor that deals with an arbitrary provider
    should assume only that the provider supports location paths
    in the abbreviated syntax format.
 
    A provider's response MUST specify "error='unsupportedSelectionType'"
    when any of the following is true:
    - the provider does not recognize (or recognizes and does not support)
      the expression language that is specified by 
SelectionType#namespaceURI
    - the provider does not support the expression that 
SelectionType#path specifies.

Gary P Cole wrote:

> 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. 
>>
>>
>
>
>
> 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. 
>
>