RE: issue "qsd-optional"

> From: Kevin Wiggen [mailto:kwiggen@xythos.com]
> Sent: Friday, October 03, 2003 11:56 PM
> To: Julian Reschke; www-webdav-dasl@w3.org
> Subject: RE: issue "qsd-optional"
>
>
>
> First, Jim Davis suggested removing QSD in April 2000 (I agreed then too
> :))
> http://lists.w3.org/Archives/Public/www-webdav-dasl/2000AprJun/0005.html

Interesting. That may have been the right decision back then, but in fact
the spec never was submitted. As of today, there is indeed an implementation
of QSD, so according to this Jim nowadays would vote for keeping it, right?

Anyway, we can and should discuss whether it should stay optional or become
required (which was the last consensus on a group meeting). From those who
think it shouldn't be required, I'd like to hear why they feel it can't be
implemented, or that implementing it would be too much work.

> We continued to discuss this at that IETF meeting and got agreement at
> that point that it would be removed.  Too bad the spec has lain dormant
> for a while.  In fact I think you (Julian) and I will be the only ones
> who are going to work on completing DASL.  I hope to be wrong here.

Well, you are. If you check the DASL mailing list, you see that Software AG
(Tamino/Slide) and the Catacomb developers have been active contributors for
some time now. In fact, I think that the Slide implementation closely
matches the current draft (and so does ours).

> It is possible to have a property that can have different operators than
> other properties.  For instance I know of a server (not Xythos) that

Right. For instance, I wouldn't expect DAV:like to work on dates. Are we
expecting servers to implement that? I guess no, so we need at least a
proper way to signal this problem.

> does not allow greater-than queries on dates.  It just can't handle them
> because the internal representation is wrong.  It is also possible that
> a server might not want to allow certain properties to have a "like" but
> rather only a "starts with" or an "equals" due to performance criteria,
> while on other properties it is possible to allow the "like" type
> because they are stored or indexed differently.  It is also possible to

So you're saying that QSD isn't expressive enough, and therefore needs to
go? I think I disagree because the same argument could be made for
DAV:basicsearch. It's *designed* to be simple. Just because a certain
protocol feature can't do anything that may be useful doesn't mean it must
go.

> imagine servers that can only sort on certain attributes and not others.

...properties? That's covered by QSD, isn't it?

> Again I am not arguing about the theoretical possibility of these
> servers doing the work, but rather the practical of what they DID code
> and how the server does work.  I have seen a lot of products that while
> it makes sense that certain searches occur, they cannot do it due to
> lack of code, load on the server, etc.  We might want to accommodate
> this.

Independantly of QSD, this needs to be handled. In some cases I'd consider
it to be a conformance problem, in other cases an error condition we should
expect (and have a RFC3253 precondition name for it). In any case, the spec
should be clear about what a client can expect to work, and what is
optional.

> That being said, I do not believe the spec can comfortably state that
> all servers must support all of their listed operators for all
> properties.  Thus operators might need to be tied to the property.

Currently the spec says:

	"The DAV:operators element describes every optional operator supported in a
query."

I understand this as that the server knows the protocol element, and has
code to act upon it. Obviously it doesn't mean that it will always work.
Maybe we just need to clarify "supported operator" here?

> Thus you can have a DASL scope that has 5 different items inside of it
> (five files in a directory for instance).  Each could have a completely
> different set of properties.  Each of those properties could have
> different operators on them.
>
> How does the UI look?  What should the server reply to the client in
> QSD?

If the same property has different types/behaviour across the scope, you
indeed have a problem. I don't think this can be solved. If the difference
is that some of the properties just aren't defined for some of the
resources, I don't see any problem at all. A condition on a non-present
property will simply evaluate to UNKNOWN, as expected.

> a) Is Xythos planning to add a search UI *at all*?
>
> All ready done in our WebUI, and has been shipping for 3 years.  Our
> webui servlet creates a DASL search and executes it against the server
> to get its response.  We plan to move it to the Xythos client at some
> point in the future.

Ah, interesting.

> b) If yes, why would optionally presenting a (non-exhaustive) list of
> searchable properties be harmful?
>
> Yes if it makes the end users interaction with the server unpredictable.
> If searchable items come and go it confuses people.  What if they want
> to search by something that was there yesterday but no longer is part on
> the non-exhaustive list because someone moved or deleted a file?  While
> this is programmatically correct (the property doesn't exist), you bet I
> will get a bug logged by that user.

That's correct but I'm not sure what you propose to do about it. Are you
saying that just because this may be confusing in some cases it's better not
to do it at all??

> My personal belief is that the only search that people really like (end
> users not machines) is google!!!  I don't want to know properties and
> such, I simply want to type in some key words and have the server figure
> it out.  The only UI I really want to ever have is one text box that the
> end user types in.  At that point how the client and/or server responds
> to it is up to implementation.

I sort of agree, but in this case we shouldn't be trying to standardized
DAV:basicsearch at all, right?

> c) QSD also offers discovery of optional operators. Wouldn't the client
> benefit from this information?
>
> Again if we can say ALL servers must support ALL operators for ALL
> properties then yes its useful, but again not reality.

I personally see a value in a protocol feature that allows me to find out
whether a server supports a specific operator at all, without having to send
a test query first. Of course it would be *better* to get more information,
but that would make QSD much more complicated. The current format may not
answer all questions, but it's very useful to discover which operators the
remote server knows at all.

So is it useful? Yes. Is it essential? Probably not. Is it good to define a
format so that servers that do want to support it can use a common protocol?
Sure.


Julian

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

Received on Saturday, 4 October 2003 06:26:09 UTC