RE: issue "qsd-optional"

> From: Kevin Wiggen [mailto:kwiggen@xythos.com]
> Sent: Friday, October 03, 2003 9:29 PM
> To: Julian Reschke; www-webdav-dasl@w3.org
> Subject: RE: issue "qsd-optional"
>
>
>
>
> I don't think QSD gives any interoperability and thus should not be part
> of the spec.  The permutations between searchable properties, possible
> operators, and scope are too complex for this spec.  I do not believe
> that anything that a server puts forth would be useful to a client not
> alone an end user.

We probably should discuss operator and property discovery separately.

Operator discovery allows a client to find out in advance whether a specific
operator is supported (and there's zero ambiguity here). This is much better
then having to try a request (besides that we currently don't have a way to
indicate which part of a query was invalid, something we'd need instead of
QSD if we won't have that) and let it fail.

Searchable property discovery is arguably of little value for
interoperability, however it can help populating a search UI (do you really
disagree here?).

> I don't think you can split searchable properties from possible
> iterators as they can be dependent on each other and on what resource
> you are on.  I do not believe putting this into the spec helps.

Wait a minute. Searchable properties (<propdesc>) and applicable operators
(<operators>) are completely separate issues. Which operators are available
solely depends on the code that executes the query, so should be trivial to
compute. If you disagree, it would be helpful if you could present an
example where you feel it's problematic to compute the <operators> element.

> When you start to get into searchable properties then you start down a
> slippery path.
>
> A)  How do we give the list of searchable properties.  Especially as
> each object can have a completely different list.  You are saying to
> give an all inclusive list, while I think this might really confuse a
> user.  There are a lot of UI types of problems I see here

Please name them.

> B)  Datatype.  As you have said, DASL has a problem with datatype, since
> I am arguing that we don't have time to wait for Webdav to do this for
> the first version of DASL, we won't have the ability to give datatype.

DASL has been specifiying type information in QSD for a very long time now.
If you see a problem here, I'd really suggest that you raise them
explicitly. If there are concerns, they need to be resolved no matter
whether QSD is optional or required. So please be more specific.

> C)  List of Values.  Then clients will want the list of valid values for
> a search.  Giving a blank box to a set of users is useless in many
> situations for a search.

I can only guess about what you're talking here. The type information in QSD
is just a label. In some cases, this will be sufficient (such as "date" or
"boolean"), in other case out-of-band information is required ("list of
states"). QSD marshalls just the identifier for the type, anything beyond
that is out-of-scope.

Having at least interoperable basic type information is IMHO still better
than having no type information at all.

> D)  The permutations that I mention above between the properties,
> operators, and scope.

Could you please be a bit more specific about what kind of problem you see
here?

> Until we solve these issues, I don't think it is worth our time to
> expose this functionality to a client.  If no clients plan on building
> this type of UI for users, it's not worth putting into the spec as we
> are not helping interoperability.

Well, I'm planning to use QSD information in our client (our server already
exposes QSD information), so, yes, this is going to be used, and specifiying
it in the spec *does* help interoperability (if it isn't in the spec, there
will be no interoperability at all).

> As a client developer, Xythos cannot build a useful UI off the
> searchable properties even if a server is responding to it.  Therefore
> this feature does not help interoperability and thus should be nixed.

a) Is Xythos planning to add a search UI *at all*?

b) If yes, why would optionally presenting a (non-exhaustive) list of
searchable properties be harmful?

c) QSD also offers discovery of optional operators. Wouldn't the client
benefit from this information?

> Again I state that QSD does not help interoperability as clients cannot
> build useful UI's.  Therefore it should be pulled from specification.

You've stated that, but I really have a hard time following your reasoning.
In particular, I'm surprised to hear this as this has been now in 4 protocol
drafts in a row, and during the last broad discussion there was even
agreement to make it required. So if you want the feature to be removed from
the spec, you really need to be more convincing.

Again: it may be useful to separate the following two issues:

1) Discovery of searchable properties and

2) Discovery of applicable operators.

I think 2) is trivial to implement and extremely useful both in interactive
and programmatic access.

Julian



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

Received on Friday, 3 October 2003 16:26:41 UTC