On 14 Dec 2016, at 17:55, Vladimir Sementsov-Ogievskiy <address@hidden> wrote:
Hmmm... Well in the '*' case, it's up to the namespace as to how it parses
things, so '*' could be prohibited entirely or mean 'return the first 20
matching' or similar. So that's less of a problem. And 'set all' doesn't exist
(unlike 'list all').
I think in the LIST case we should allow the server to omit contexts under
certain circumstances, and allow SET to return ETOOBIG.
We can't prohibit '*' as query string as implementation defined. And we
shouldn't (I think) define its meaning.
Those two statements appear to me to contradict each other. The current
documentation *does* define the query string (to the right of the colon) as
implementation defined. I'm thus not sure what you mean.
Opposite, we can define, that query must not select more than 20 contexts, but
I'm not sure that this is good.
Each query can select from only one namespace in the current document (Wouter
explained why). However, you can specify multiple queries.
I don't think we need to define a hard limit of a particular number.
So, do you mean
list('backup:modtime>*') -> empty list
The result of that would depend on however the 'backup' context was defined,
meaning it had the options of:
* ETOOBIG
* Listing some subset of available contexts (arguably 'none' is a subset)
set('backup:modtime>*') -> ETOOBIG
Again, the result of that would depend on however the 'backup' context was
defined, meaning it had the options of:
* ETOOBIG
* Listing some subset of available contexts (arguably 'none' is a subset)
... and it need not make the same choice as above, but I agree it would be
logical for it to do so.
As any form of wildcarding within a query refers to one particular namespace
(as a query by its nature specifies a single namespace), we don't have to worry
about the way wildcarding works in the standard, as Wouter pointed out. We
merely need to provide that ETOOBIG and listing a subset are acceptable
responses.
What we do need to decide is what the response to list() (i.e. a list with a
zero length list of queries) does. It's currently defined to return every
context from every namespace. Options would include
* ETOOBIG
* Listing some subset of available contexts (arguably 'none' is a subset)
* Allowing abbreviation of algorithmically specified contexts (e.g. in this
case just returning 'backup:' to represent all available backup contexts)