[mdx] MDQ questions

[Tom Scavo]

On Mon, Nov 25, 2013 at 11:57 AM, Ian Young <ian at iay.org.uk> wrote:
>
> On 25 Nov 2013, at 16:30, Tom Scavo <trscavo at gmail.com> wrote:
>>
>> Ian, since we are coming back to this after a long hiatus, would you
>> mind rephrasing the question in its entirety? (As it stands, I can
>> only think of questions, not answers.)
>
> Sure, Tom, that makes sense.

Thanks Ian.

>> All Metadata Query requests MUST use the URL format:
>>
>>    <base_url>/entities/{ID}+{ID}+...
>>    The request MUST contain at least one identifier but MAY contain more
>>    than one.  Each identifier must be properly URL encoded.  If more
>>    than one identifier is used the returned metadata MUST have been
>>    labelled with each identifier.  That is to say a search with multiple
>>    identifiers results in the intersection of the metadata that would be
>>    retrieved by searching for each identifier individually.
>
> (Those {ID} terms have been rewritten as <ID> in the current text, and will become ABNF next time round.)
>
> The first question is: What value is that '+' operator delivering, in terms of enabling actual use cases?

Those are two separate questions (or I prefer to parse them as such :)

You're assuming '+' is being used as operator, which is not at all
clear from the definition. If that is true, however, then I feel
strongly that it is the *wrong operator* since '+' signifies union,
not intersection.

In algebra, intersection is multiplicative, and so the proper operator
here is juxtaposition. If you juxtapose a bunch of IDs, and then
URL-encode the result, you end up with '+' signs as above. In that
case, however, '+' is not an operator.

So anyway I look at it, the above notation is an abomination :-)

To answer your other question, consider "all discoverable IdPs." Isn't
that a simple use case?

> If we have an answer to that, I'd like to capture it. If we *don't* have an answer to that, my alternative is to strike it and instead just have a single term. It's better to sweep away the complexity, in my view, if we don't actually need it.

I don't think that's possible with sweeping away a bunch of
functionality at the same time.

Tom