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: More about the variable matching question at the end of the last TC call


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]