Subject: Stored queries.

From: Doug Royer <[email-masked]>
Date: Mon, 09 Feb 2004 21:57:56 -0700

Bruce and I had a very small private dialog about stored queries.

Bruce agrees that if we (a) add STORED-VQUERY to the capability
reply and (b) add a new REQUEST-STATUS code to mean "Unsupported command
or property", then he would not object.

So I *think* that is now a non-issue.

Comments Please !!!

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                               | Cell:   (208)520-4044

              We Do Standards - You Need Standards

---

From: [email-masked]
Date: Tue, 10 Feb 2004 11:39:46 -0500

> So I *think* that is now a non-issue.

2 brief comments:

1: As long as the model is changed so that stored queries are not 
implicity required and that the feature is identified by CAPABILITY then 
this is good.  It should be noted though that although my objection 
lessons, it does _not_ mean that the issues with stored queriy design are 
gone (see WG archive for discussion of them between myself and Andrea 
~Jan-Mar 2003 and some ~Nov 2002 postings for what they are).

2: There probably should also be some small added text to the CAPABILITY 
section describing STORED-VQUERY to make it clear that if the CS does not 
support the use of stored VQUERYs then the CUA is responsible for manually 
crafting the VQUERY in order to access the data in the CS.  This should be 
intuitive but Ive learned that adding a single line or two now saves much 
reinterpretation later on...

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Tim Hare <[email-masked]>
Date: Tue, 10 Feb 2004 20:37:09 -0500

Would STORED-VQUERY be a mandatory part of the capability reply? If so, I 
agree with the method, this is what I proposed for handling CALSCALE 
(especially for non-Gregorian scales) some time ago.

I would like to see a call for consensus on this issue (_and_ CALSCALE for 
that matter). CALSCALE is in the open-groupware bugzilla as an issue, and 
this probably should be also.

I would also like to ask: are there other capabilities we've overlooked in 
the GET-CAPABILITY request/response? And (although I am certain I do not 
want to propose we do it in this version of CAP) is the response getting so 
large that we should group capabilities into families and have responses 
for whole families of capabilities?

Tim

---

From: Doug Royer <[email-masked]>
Date: Tue, 10 Feb 2004 19:45:55 -0700

Tim Hare wrote:

>
> Would STORED-VQUERY be a mandatory part of the capability reply?

We should add ...

    New property - STORED-VQUERY. If the value contains <RFC-XXXX>
    (WHERE XXXX will be replaced by THIS memos RFC) they are supported
    as defined in this RFC.   If empty or not supplied then the endpoint 
does
    not support stored vqueries.

Then add STORED-VQUERY to the 'cap-vreply' as *dstored-vquery

And add something like this to the GET-CAPABILITY section.

  Any future BOOLEAN property extensions to the GET-CAPABILITY reply
  must be designed so that FALSE indicates the feature is not supported. Any
  feature not listed in a GET-CAPABILITY reply must be presumed to be
  not supported or the value not available.

--