[mdx] MDQ questions

[Ian Young]

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

> On Mon, Nov 25, 2013 at 11:13 AM, Ian Young <ian at iay.org.uk> wrote:
>> 
>> Coming back to my quoted paragraph above, though, and this is really a question for all: *can* anyone think of a real use case for the union operator that isn't covered by IDs that designate arbitrary groups? If not, I am tempted to suggest that we consider dropping it entirely; it would simplify a lot of the questions about encoding the '+' and the like.
> 
> 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.

The -00 document includes this:

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

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 would still want to retain the convention that an identifier starting with '{' was special, to provide an extension point. This would obviously be compatible with the current use of "{sha1}id" to express SHA-1 transformed identifiers.

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