Re: SEARCH by last path segment, Was: SEARCH for displayname

Kevin Wiggen wrote:
> <KW> I am not disagreeing that with BINDS the <last-pathsegment> will
> make this more difficult, but does it really matter where the clause
> lives?  Yes having the power of putting <last-pathsegment> in the WHERE
> might make things hard for some implementations, it's not impossible.  I
> truly believe that it is something people will want to be able to do.
> Supporting multiple scopes is hard based on your implementation also and
> that made it in the spec.  

Yep, but only as an *optional* feature...

> You can still 
> a)  create the matching set of objects based on non <last-pathsegment>
> parts of the where (you can do this whether the <last-pathsegment> is in
> the where or not
> b)  apply the scope and the <last-pathsegment>.  Yes you might need to
> be more intelligent here as the <last-pathsegment> might be intertwined
> with other WHERE segments.

Well, that can get really hard. I'm not going to add this feature unless 
we can make it reasonably straightforward to implement...

> <KW> Same could be said for the <d:contains> which IS part of the WHERE
> clause.  Simply say this cannot be used in the SELECT and is simply
> there to help narrow down a search </KW>
> 
> I think it is somewhat humorous that I am usually arguing to keep things
> simple and in this case you are saying my suggestion is too hard :)

Isn't it?

Some thoughts:

- the optimal number of optional features in a spec is zero (I've stolen 
this, I'm not sure who said it first)

- let's concentrate on resolve the open issues in the spec instead of 
continuously inventing new ones...

> In the end if you DO want to simply add it to the scope (which I think
> takes away some power for clients and should be thought through), why
> not allow someone to create <WHERE> type syntax with <and> <or> <not> on
> a <last-pathsegment> type of scope xml fragmant.  Then we don't have to
> argue or explain what the ordering of <AND> and <OR> etc is and the
> client can make it up themselves.

See above. Unless we can agree on something simple, I'll prefer not to 
it at all (for now, that is).

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Tuesday, 18 November 2003 13:53:29 UTC