[mdx] MDQ questions

[Ian Young]

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

> On Mon, Nov 25, 2013 at 1:31 PM, Ian Young <ian at iay.org.uk> wrote:
>> 
>> 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?
>>> 
>>>> 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'm okay with sweeping it all under the rug, as long as we admit it
> may come back to haunt us at a later date.

I wouldn't put it quite like that, obviously, but if we do narrow the spec down I would want to be very careful to make sure that we can widen it again later.

> Indeed, I would much rather
> do that than use the '+' operator inappropriately.

It's not my intention to make that the choice, although I share your distaste for misleading notation to some degree.

>>> 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.
> 
> I'm not sure I like playing this game since you can counter any
> hypothetical example I cook up. If set algebra were not useful, why do
> we see it just about anywhere we look?

Set algebra is of course useful in all sorts of places; that doesn't mean that every specification that can include it should include it because it might be useful at some point in the future. I'm not particularly fond of XP principles in general, but their YAGNI is really at the heart of what I am trying to achieve here:

	http://en.wikipedia.org/wiki/You_aren't_gonna_need_it

So when I'm asking for a use case, I'm not asking people to imagine circumstances in which something might come in handy as an alternative, I'm asking for evidence of a relatively near term concrete use case which would be hard to achieve if the feature was left out.

> My previous example was weak since it involved a characteristic of a
> specific entity type (IdPs).

The more important weakness in that example is that the same goal could be achieved with a much simpler mechanism, that of defining an identifier corresponding to that particular collection however defined. Moreover, the simpler approach is also *better* in a number of ways: it means you can precompute the result offline, pre-sign it, not have to worry about ordering of terms and so forth.

To support the presence in the spec of intersection, or union, or your list of potential entity characteristics (which is also partly the entity attributes discussion, I suppose) what's needed is an explanation as to why expressing those in the more general way is superior for either or both parties in the transaction to just assigning an arbitrary identifier to the collection.

Speaking as someone who would be a deployer of this technology, I really can't see any likelihood that I'd want to deploy something that supported arbitrary queries. I can see the need to address specific use cases such as "give me the JSON metadata for all discoverable IdPs" but an arbitrary identifier is sufficient for the ones I can think of.

	-- 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/534f8eac/attachment.bin>