Subject: Re: (#2) 4.1.1 Grammar for Search Mechanism

From: [email-masked]
Date: Mon, 28 Jan 2002 12:33:32 -0500

Doug wrote:
>                (f) SELECT * FROM VEVENT WHERE
>                     TRIGGER < 20020201T000000Z
>                     AND TRIGGER > 20020101T000000Z

A couple of things.  First, you should have text in the Note section that 
follows the example describing what case (f) is trying to do (esp. since 
it relates to the NOT VALID case (h) below it).  Second, if the example is 
corrected to be:

                (f) SELECT * FROM VEVENT WHERE
                     VALARM.TRIGGER < 20020201T000000Z
                     AND VALARM.TRIGGER > 20020101T000000Z

as previously noted then there appears to be an implicit assumption in the 
query that anything in the WHERE clause is contained w/in the entity given 
in the FROM clause.  That is, a VALARM is contained w/in a VEVENT.  Is 
this a correct assumption?  Item (4)is not 100% clear on the issue of containment but I suspect it was 
intended to include it (by deriving it by applying (1) to the logic).

It has an impact on how future expansion of the model goes as well as how 
the CS handles data scoping of the query.  That is, if someone adds a new 
VWHIZBANG component that is contained w/in a VEVENT then a CUA could easly 
query based on its values by simply substituting VWHIZBANG for VALARM in 
the example above.  All is just happy and fine.

However when I want to do something like search for RELATED-TO entities, 
it is murky as to how I would query a VAGENDA for any entry w/a 
"UID:ABCDEF12345".  That is, I perform the search in (f) and I find that 
it has a RELATED-TO property on it.  I now want to find the related entity 
for any one of a number of reasons..  The related component may be a 
VEVENT, VTODO, VJOURNAL or some as yet defined entity (ie: VFUBAR). 

The simplest approach is to do multiple searches, 1 for each entity type 
but that assumes the CUA knows about every available entity.  However, I 
would expect that because of the containment design of VAGENDA->(VEVENT / 
VTODO / VJOURNAL / VFUBAR) that I could specify a search much like (f) but 
its not clear if I can wildcard the component type.  Would:

                (x) SELECT * FROM VAGENDA WHERE
                     *.UID = "ABCDEF12345"

be doable / legal??  Alternately my CUA could try to find the component 
that the VEVENT is RELATED-TO by making multiple queries like:

                (x1) SELECT * FROM VEVENT WHERE
                     UID = "ABCDEF12345"

if that fails to find a result then try:

                (x2) SELECT * FROM VTODO WHERE
                     UID = "ABCDEF12345"

if that fails to find a result then try:

                (x3) SELECT * FROM VJOURNAL WHERE
                     UID = "ABCDEF12345"

if that fails to find a result then tell the user that the RELATED-TO 
component is not found (when in fact it does exist but the CUA does not 
know to check for VFUBAR components in the VAGENDA). 

Granted my CUA my not grok whats in a VFUBAR but if it follows the RFC 
2445 formatting convention it should be able to at least parse and 
identify its properties, parameters, etc.  This is different from claiming 
that "the RELATED-TO link is 'broken' because no linked entry can be 
found."

Just a thought about future possible crocs.  Im not sure the best way to 
address this yet but perhaps others do...

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: Patrice Lapierre <[email-masked]>
Date: 28 Jan 2002 16:43:59 -0500

On Mon, 2002-01-28 at 12:33, [email-masked] wrote:
> ...
> be doable / legal?? 

  AFAIK it's not currently legal with the current proposition.

> Alternately my CUA could try to find the component 

 Another alternative (not currently legal) would be to allow a 
wildcard (*) in the FROM clause.

   e.g,  SELECT * FROM * WHERE UID = "ABCDEF12345"

 Such a construct could also be useful for Bernard's proposition
for VCARs (i.e., single SCOPE properties for many component types). 

> ...

---

From: Doug Royer <[email-masked]>
Date: Mon, 28 Jan 2002 15:24:44 -0700

> for VCARs (i.e., single SCOPE properties for many component types).

One of the debates over the last proposal was (just over the
last few weeks) is that people did NOT wat to have to figure
out how to do cross-component joins. Now you are proposing
them again?  If so, stay with SQL-MIN - it allowed them,
well just add the PARAM() funciton and we are back were
we started.

-Doug

---

From: Doug Royer <[email-masked]>
Date: Mon, 28 Jan 2002 15:48:40 -0700

[email-masked] wrote:

> 
> The simplest approach is to do multiple searches, 1 for each entity
> type but that assumes the CUA knows about every available entity.
>  However, I would expect that because of the containment design of
> VAGENDA->(VEVENT / VTODO / VJOURNAL / VFUBAR) that I could specify a
> search much like (f) but its not clear if I can wildcard the component
> type.  Would:
> 

This WG seems to have opted out for cross component joins.
So, no; not doable.

> Alternately my CUA could try to find the
> component that the VEVENT is RELATED-TO by making multiple queries
> like:
> 

Or do them in ONE VQUERY:

	BEGIN:VQUERY
	QUERY:SELECT * FROM VEVENT WHERE UID = 'ABCDEF12345'
	QUERY:SELECT * FROM VTODO WHERE UID = 'ABCDEF12345'
	QUERY:SELECT * FROM VJOURNAL WHERE UID = 'ABCDEF12345'
	END:VQUERY

> component is not found (when in fact it does exist but the CUA does
> not know to check for VFUBAR components in the VAGENDA).

Or the data provieded is bogus in the original component.

Or perhaps you don't have access to that UID and the VCARs
don't even allow you to know that it is there.

> identify its properties, parameters, etc.  This is different from
> claiming that "the RELATED-TO link is 'broken' because no linked entry
> can be found."

Unless is does not exist, how would you ever know if we don't
require that they be valid?

What if the RELATED-TO component has been deleted?

---

From: Alan Davies <[email-masked]>
Date: Mon, 28 Jan 2002 18:55:46 -0500

>This WG seems to have opted out for cross component joins.

I don't see that that's an example of a cross-component join;
it's really just misuse of the "*", which should only be used
as part of the SELECT clause.

There aren't really any common operations that need cross-component
joins, and the few half sensible ones could be completed with
multiple queries anyway (e.g. "find all of the Events whose Attendees
are also Attendees of a given Event").

>         QUERY:SELECT * FROM VJOURNAL WHERE UID = 'ABCDEF12345'

This seemed a much clearer and more flexible way to specify the
"select from whichever component matches" type of operation.

--Alan