[mdx] MDQ questions

[Ian Young]

On 25 Nov 2013, at 18:05, Tom Scavo <trscavo at gmail.com> wrote:

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

That's the intention, though. I think we all agree that the spec in this area leaves a lot to be desired (which is why I'm trying to understand whether we can just dump this part altogether).

> If that is true, however, then I feel
> strongly that it is the *wrong operator* since '+' signifies union,
> not intersection.

You mean to say, I think, that "+" is the wrong denotation for the intersection operator. I don't disagree, but the question isn't what denotation we should use for intersection, but whether we need to express that operator (or any operator) at all.

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

It's a possible use case, but I'm not convinced that it's a particularly desirable one as it requires that you'd want to express that by composition of two other terms rather than just defining a single identifier for the composite.

So, yes, a server which defined ID1 to mean "all IdPs" and ID2 to mean "all discoverable things" (and let's leave aside the question of whether the latter is a use case for an entity attribute notation, that's an orthogonal issue) could respond to "ID1 intersection ID2" with "all discoverable IdPs". But is that really likely to be how a server would want to express that set; wouldn't a third pre-defined identifier be better for it in every way?

The only case in which some kind of composition might be a better way to express that set would be one in which the server was prepared to process completely arbitrary (or perhaps just unpredictable) requests, and I don't see anyone feeling that was something they'd want to deploy.

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

True. Is it functionality anyone will ever deploy, though? I'm willing to be convinced, but at present I'm not seeing it.

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5943 bytes
Desc: not available
URL: <http://lists.iay.org.uk/pipermail/mdx-iay.org.uk/attachments/20131125/3480ab26/attachment.bin>