Subject: CAP-12-a: 9.6 VQUERY Component - QUERYID/NAME

From: [email-masked]
Date: Thu, 4 Sep 2003 09:31:09 -0400

In CAP-12-a, under Section 9.6 VQUERY Component is written:

                                             Normally "NAME" and
   "QUERYID" properties are used when looking for a correct stored
   "VQUERY" component, or when storing a "VQUERY" component.

Im curious to know when we decided that the NAME property was to be used 
for identifying the VQUERY? 

If its just the "localizable display name" then what use is it in looking 
for the particular VQUERY?  Isn't that the sole role for the QUERYID 
property?  If not, when is NAME _not_ used (since the text says 
"Normally"...)?

Since later text says:

   For a search, if the "TARGET" property is supplied in a "VQUERY"
   component, then the CS is to search for the query in the calid
   supplied by the "TARGET" property value.

I suspect that the 1st bit above is just poor phrasing and there is no 
actual intent of using NAME in some unspecified combination with QUERYID. 
However I dont want to second guess Dougs intent here. 

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: Doug Royer <[email-masked]>
Date: Thu, 04 Sep 2003 09:19:09 -0600

> for identifying the VQUERY?  

Check the archives, I think the requirement came from CS&T and
there were no objections.

> If its just the "localizable display name" then what use is it in 
> looking for the particular VQUERY?  Isn't that the sole role for the 
> QUERYID property?  If not, when is NAME _not_ used (since the text says 
> "Normally"...)?

Correct. They wanted a localizable display name. Not everyone has
to support just one locale at a time.

> actual intent of using NAME in some unspecified combination with 
> QUERYID.  However I dont want to second guess Dougs intent here.  

I did not write that text. I'll change it to remove NAME:

  The "QUERYID" property specifies the local identifier for
  a stored "VQUERY" component. The "NAME" property specifies
  a localizable display name of a stored "VQUERY" component.
  Normally the "QUERYID" property is used when looking for a correct
  stored "VQUERY" component, or when storing a "VQUERY" component.

TARGET is used so that you can use stored QUERIES that are not in
the current CMD/TARGET, such as when you have access to more than
one calendar.

-- 

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

                 We Do Standards - You Need Standards

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 04 Sep 2003 12:57:45 -0400

Doug Royer wrote:

>> Im curious to know when we decided that the NAME property was to be 
>> used for identifying the VQUERY?  
> 
> 

In February 2002, Steltor (formerly CS&T, and now Oracle) proposed
to rename the property QUERYNAME to QUERYID and to add a new property
NAME to specify a localizable display name.

VQUERY components should be referred to with their unique QUERYID not
their NAME which may not be unique.

Cheers,
Bernard

>> QUERYID property?  If not, when is NAME _not_ used (since the text 
>> says "Normally"...)?
> 
>

---

From: [email-masked]
Date: Thu, 4 Sep 2003 12:45:19 -0400

> > Im curious to know when we decided that the NAME property was to be 
used 
> there were no objections.

What permutations of search do I use?  Using NAME and QUERY and some other 
values do not help since I get TONS of unrelated matches.  You seem to 
recall it so how about at least a Subject I can use?

The idea is interesting but there are LOTS of unanswered questions 
involved in using localized strings for identification.  The NAME is there 
as a friendly/display name for the QUERY ("What the hell does 
QUERYID:Fizbin32 do??" vs "Ah, QUERYID:Fizbin32 is displayed w/the 
'NAME:Fínd all calendars that Andrè owns'.") and not as part of searching 
for it.

Even if it was suggested, there is NO prose in CAP _now_ for when NAME is 
used, how it is to be used or when it is NOT used in conjunction with 
QUERYID in a VQUERY.  If (and thats a big if) the WG decides to use NAME 
in addition to QUERYID as part of VQUERY location then issues like dealing 
with specifying localization code pages used, etc need to be answered. 

I hope George or any of the former CS&T/Steltor folks can chime in here 
and help us out here since they are credited w/the proposal.

> to support just one locale at a time.

The abilty to have > 1 NAME property per component is understandable but 
its not relevant to the need to finding a particular query. 

I can have multiple queries all with NAME:Widget but each MUST have a 
different QUERYID per VAGENDA.  Since QUERYIDs are unique per VAGENDA and 
NAMEs are not, what good is searching on both QUERYID and NAME??  None 
really since the NAME is only intended for display purposes rather than 
actual identification.

> the current CMD/TARGET, such as when you have access to more than

Thank you.  Also, strike the word "Normally" from the last sentence too. 
Otherwise you imply there is a 'non-normal' case but you never say what it 
is.  After all, how would you identify a particular stored query w/o a 
QUERYID?

Bruce

---

From: Doug Royer <[email-masked]>
Date: Thu, 04 Sep 2003 11:37:21 -0600

[email-masked] wrote:
> What permutations of search do I use? 

I do not find it odd that you can only seem to find opinions that
aggree with yours.

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 04 Sep 2003 11:51:35 -0600

[email-masked] wrote:

> involved in using localized strings for identification.  The NAME is 
> there as a friendly/display name for the QUERY ("What the hell does 
> 'NAME:Fínd all calendars that Andrè owns'.") and not as part of 
> searching for it.

(1) Bruce - please read all of CAP - not just the diffs.

(2) You can search for any component by ANY property value.
     Are you proposing that we limit searching of VQUERYs to
     be less than other components?

 > Even if it was suggested, there is NO prose in CAP _now_ for when NAME
 > is used, how it is to be used or when it is NOT used in conjunction
 > with QUERYID in a VQUERY.  If (and thats a big if) the WG decides to
 > use NAME in addition to QUERYID as part of VQUERY location then issues
 > like dealing with specifying localization code pages used, etc need to
 > be answered.

(1) Did you bother to read section 8.23?

(2) You can search for any component by ANY property value.
     Are you proposing that we limit searching of VQUERYs to
     be less than other components?

By your removal and (so far) non responsiveness to your incorrect
octet count conclusion, are you agreeing that it does indeed save
one round trip and twice the stored VQUERY size in OCTETS
at a minimum now so it is in fact 'efficient'?

Plus we use UID to uniqly identify several components.
We use CSID to uniquly identify one type of component.
We have a VQUERY component - are you proposing we have
no unique way to store/fetch/modify/delete them?

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 04 Sep 2003 11:58:47 -0600

[email-masked] wrote:
>  Otherwise you imply there is a 'non-normal' case but you never say what 
> it is.  After all, how would you identify a particular stored query w/o 
> a QUERYID?

Identify != 'looking for' as the following is as valid:

	SELECT VQUERY FROM VAGENDA WHERE 'some ... locale string' IN NAME

as:

	SELECT VQUERY FROM VAGENDA WHERE QUERYID = '123'

VQUERY is a component searchable like any other.

--

---

From: [email-masked]
Date: Thu, 4 Sep 2003 17:32:08 -0400

> I do not find it odd that you can only seem to find opinions that

Im asking you for your search criteria so I can use them to find the posts 
you were referring to.  If you wont provide citations (Dates, Subjects, 
Posters, actual snippets), the least you can do is provide the search 
phrases you used.  Unless you can't...

Bruce

---

From: [email-masked]
Date: Thu, 4 Sep 2003 17:58:03 -0400

> (1) Bruce - please read all of CAP - not just the diffs.

Doug - please post a summary of the changes between versions instead of 
saying "do the diffs yourself" (paraphrased).  I did and now you say, go 
read the drafts!?  Sorry but Im NOT going to reread ~140 pages every time 
a new draft is reissued since by now there should not be lots of changes 
going in.

Its a typical editors task to provide a summary of the changes, not say 
"do the diffs yourself" (paraphrased; you're welcome by the way) and then 
complain in the next posting that Im actually doing that.

>      be less than other components?

How the heck did you get that from either my proposal to remove all 
references to stored queries OR to my comment about NAME being incorrectly 
used in finding the a particular stored query in a particular TARGET? This 
is totally a nonsequitor.

> (1) Did you bother to read section 8.23?

In fact I did.  Section 8.23 NAME Property says NOTHING about using NAME 
as part of any criteria for identifying queries.

Actually it does not matter now that you've said you will revise the 
questionable text in Section 9.6 VQUERY Component it doesn't really matter 
but Im still interested in what I missed.

>      be less than other components?

Ahh, I think I see now; you have confused SEARCHing with the act of 
finding a particular stored query in a particular TARGET that I cited and 
have been referring to. 

I have been referring to the questionable text in Section 9.6 VQUERY 
Component that said that "NAME" was used "when looking for a correct 
stored "VQUERY" component" and you have incorrectly extended this to all 
SEARCHing based on the NAME property. 

> at a minimum now so it is in fact 'efficient'?

I have NO clue where you got the idea in your head that the CUA is going 
to have to retrieve a query string from the CS only to stuff it into a 
command buffer and then send it back to the CS.  Perhaps the same place 
you got your definition of the word original.

Ive already explained several times that this is incorrect on your part 
and Ive even given pseudocode on how the CUA does it all itself.  Beyond 
that, I cannot do more. 

I would still appreciate an explaination of why you think the CUA MUST 
load the query string from the CS in the first place?  Is that how you 
prototyped it?  Or is there just some other nuance of phrasing Im not 
getting?   Arnaud, can you help me out here?

Bruce

---

From: [email-masked]
Date: Thu, 4 Sep 2003 18:13:08 -0400

> VQUERY is a component searchable like any other.

You are once again confusing SEARCHing for VQUERYs with using "looking 
for" VQUERYs to use in a command.  The former is above, the latter is:

BEGIN:VQUERY
TARGET:cap:FrodosCalendar
QUERYID:EventsInTheShire
END:VQUERY

where whatever command is told to use the query identified by 
QUERYID:EventsInTheShire in VAGENDA FrodosCalendar rather than another 
TARGETed VAGENDA to find the entries that are to be processed by the 
command.  At least thats what I take from:

   For a search, if the "TARGET" property is supplied in a "VQUERY"
   component, then the CS is to search for the query in the CALID
   supplied by the "TARGET" property value.

I did not take "a search" above to be "a SEARCH" as in a SEARCH command. I 
took this to be "Use the QUERYID value to find the desired actual query in 
the specified TARGET" rather than limiting it to an actual SEARCH or 
SELECT as you suggest.  Is this not consistant with the comments in the 
ABNF for VQUERY:

             ; 'queryid' is OPTIONAL but MUST NOT occur
             ; more than once. If the "TARGET" property
             ; is supplied then the "QUERYID" property
             ; MUST BE supplied.

and the text:

                                        ...looking for a correct stored
   "VQUERY" component...

If not then the comments and the prose under 9.6 need to be better phrased 
to reflect the correct intent.

In addition, if the intent of "For a search" was to imply a SEARCH command 
then I have to ask why the same "find the query" logic is not applicable 
to other commands like DELETE or MOVE?

Bruce

---

From: Doug Royer <[email-masked]>
Date: Thu, 04 Sep 2003 18:33:30 -0600

[email-masked] wrote:
> references to stored queries OR to my comment about NAME being 
> incorrectly used in finding the a particular stored query in a 
> particular TARGET?  This is totally a nonsequitor.

So you want to not be able to store some types components.
But other type components you want to be able to save.
Correct?

The 'NAME' issue I think we resolved.

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 04 Sep 2003 18:45:39 -0600

> for" VQUERYs to use in a command.  The former is above, the latter is:

Sorry, now I understand - yes I agree, 'Normally' gone.

--