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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xdi] More about the variable matching question at the end of the last TC call


Something feels strange about including cardinality in the variable syntax, a variable can either match or not match.
Maybe cardinality should not be part of the variable syntax, but a property of a particular request (a message or operation parameter similar to <$deref>).

In all other matching syntaxes I know, you don't specify how many results you want, you just specify a pattern for the results.
Think of filename wildcards, or SQL WHERE clauses, or regular expressions.

If we want to allow something like {0-2}, then to me it would make more sense for that to be the depth, rather than cardinality of results.

Markus


On Mon, Mar 2, 2015 at 6:52 AM, =Drummond Reed <drummond@respectnetwork.com> wrote:
This thread is to continue discussion of question at the end of last Friday's TC call that we didn't have time to finish:
 

Variable Matching Question

One final question arose at the end of the call with regard to the variable matching rules for the following two expressions:

  1. =markus{}<#tel>

  2. =markus{<#tel>}

The question is: do they both evaluate to the same set of matching nodes? Or does the first one specify a single match because it ends in concrete singleton?


This is the answer Markus sent me:
 

Let's add a few more patterns here:

3. =markus{}{<#tel>}
4. =markus{<#>}<#tel>
5. =markus{<#>}{<#tel>}
6. =markus{}{<#>}<#tel>
7. =markus{}{<#>}{<#tel>}

Then I think the patterns would match as follows:

A  =markus<#tel>                                  1, 2, 3
B  =markus[<#tel>]<!:uuid:1111>                      2, 3
C  =markus<#home><#tel>                           1,    3, 4, 5, 6, 7
D  =markus<#home>[<#tel>]<!:uuid:1111>                  3,    5,    7
E  =markus#profile<#tel>                          1,    3
F  =markus#profile[<#tel>]<!:uuid:1111>                 3
G  =markus#profile<#home><#tel>                   1,    3,       6, 7
H  =markus#profile<#home>[<#tel>]<!:uuid:1111>          3,          7

This is my intuition, I'd need a bit more time to fully put that into words..

I think this means that the {} common variable may match any number of arcs (including zero), whereas all others have to match at least 1 arc.

I agree that:
  1. The common variable {} can match any number and kind of arcs, including zero.
  2. Typed variables must match at least one arc (and it must be of that type).
At first I was thinking that a typed variable like {<#tel>} was not positional, i.e., like the common variable, an otherwise undefined typed variable would match anything beneath it. However, once I studied your chart, it made sense. The default is that a typed variable is positional, which is why #2 will only match if a <#tel> or [<#tel>] immediately follows =markus. To make a typed variable non-positional, proceed it with a common variable like #3, which matches A-H.

I would still like a really simple way to express the variable matching cardinality without needing to use a defined variable. Here's an idea: what if we used a cardinality _expression_ inside the common variable to do this? The cardinality _expression_ would not change the meaning of the common variable—it could still match 0-n instances at any depth—but it would specify "the number of allowable matches". For example:

=markus{1}<#tel> <-- would match exactly one instance of a <$tel> singleton at any depth
=markus{1}{<#tel>} <-- would match exactly one instance of a <$tel> singleton or collection member at any depth
=markus{0-2}<#tel> <-- would match zero, one, or two instances of a <$tel> singleton at any depth (zero means a match is optional)
=markus{0-2}{<#tel>} <-- would match zero, one, or two instances of a <$tel> singleton or collection member at any depth

A simple inline cardinality _expression_ like this would make it very easy to express the two most common constraints in an XDI query: cardinality and type—without having to use a defined variable.

Thoughts?







[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]