RE: more detailed version of query schema for simplesearch

(1) Jim Davis: "How would you state capabilities of "all" 
properties without listing them all?"

    I wouldn't. I would just list all the properties along 
    with their capabilities/attributes. I don't think the 
    consumer (i.e., the client appl.)
    would benefit from the "all" approach, nor would the
    server code. It is simplest for the server just to
    go into a loop that spits out each property along 
    with its attributes, and for the client to just create a 
    table and keep adding rows to it, one for each property
    plus its capabilites/attributes. That is extremely
    simple, it handles all collections, and there are no
    special cases in the code on either side.

    I don't believe that specifying capabilities/attributes 
    that apply to all properties is really necessary,
    and it's certainly not adequate, because it obviously
    doesn't always apply. Since the straightforward approach
    always works, lets go with it and let actual
    experience tell us if there is any real demand for
    the "all" approach.

(1, cont.) "I don't think it's more extensible than my approach."

    You may be right. So, let me withdraw that claim.

(2) "Yes, I took the operator list out on the theory that ...".

    We are chartered to spec. a way to advertise the query 
    capaibilities of collections. To me, this consists primarily
    of advertising the properties (and their capabilities/attributes)
    and the query operators that are supported (and the
    limitations on the forms of their operands) . I don't think that
    just having the operators listed in the spec. is adequate.
    I think they have to be advertised by collections:

    I don't agree that "contains" can be mandatory, because of 
    the number of existing document management systems 
    with Billions of dollars in sales that do not provide
    content based retrieval. Obviously, there are some
    systems that can get along quite well without "contains".
    But "contains" is potentially so useful in some systems, 
    that it probably ought to be in the DASL 1.0 spec.
    This implies that "contains" must be an optional operator
    in the 1.0 spec. (We might get away with making
    the SQL "LIKE" pattern match operator mandatory,
    but "LIKE" is a far cry from true content based retrieval.)
    Hence, collections have to advertise their operators.

    I believe that that our deepest disagreement is on 
    whether simplesearch should be merely the initial 
    features of a query grammar based on an extensible
    framework, or whether simpilesearch should be
    a limited, never-to-be-extended grammar,
    and we deliberately intend to propose another, 
    different (but probably similar) search grammar 
    that IS extensible in the next version of the DASL spec. 
    I take the former position, and you take the latter. 

    At the Redmond meeting, it is my recollection
    that when asked during my presentation, 
    possibly excepting you, the
    people attending were either silent or agreed with
    having extensibility, assuming we didn't have to give
    up anything. That is, all else being equal, an 
    extensible framework would clearly be better. 

    Query has been on the well beaten path for
    so many decades, and I have had so much
    experience with query and DBMS design and
    implementation, that I am morally certain
    that we can release an extensible framework
    for DASL 1.0 without giving up anything of
    importance. I don't think it's hard.
    This is especially true now that
    we have decided not to be bound by the
    artifacts (e.g., redundant tags) and 
    limitations of XML DTD syntax.

    An existence proof of such a grammar should 
    suffice to resolve this disagreement, I would 
    think. (I'm assuming that you're not against 
    extensibility per se, but are concerned that
    we will have to give something up that you
    consider important in order to achieve it. If
    you think extensibility is bad per se, I would like
    to hear why.) Saveen is working on such a 
    grammar. I can also produce one if necessary.

Alan Babich

> -----Original Message-----
> From:	Jim Davis [SMTP:jdavis@parc.xerox.com]
> Sent:	June 26, 1998 7:27 AM
> To:	www-webdav-dasl@w3.org
> Subject:	RE: more detailed version of query schema for
> simplesearch
> 
> 	From: "Babich, Alan" <ABabich@filenet.com>
> 
> 	(1)... I would rather
> 	see a syntax where the property name is mentioned
> 	once, and the capabilities of the property (i.e.,
> 	selectable, sortable, orderable) come immediately 
> 	afterward. 
> 
> How would you state capabilities of "all" properties, without listing
> them all?
> 
> 	And it would be more amenable to
> 	adding capabilities to the properties in the
> 	future.
> 
> I don't think it's any more extensible than my approach.  Either one
> adds a new section and lists properties under it, or one adds new tags
> to the list of properties.  In any case extensibility isn't an issue
> for simplesearch.  It's not extensible.  If you define a new
> capability you'll define a new grammar.
> 
> 	(2) The collection must advertise the operators that it supports
> 	as well as the properties. (Your current proposal is limited to
> 	just the properties.)
> 
> Yes I took the operator list out, on the theory that simplesearch does
> not have an extensible operators, nor have we decided whether there
> are any optional operators, or whether all are mandatory.  If the
> list reaches consensus that these are needed, I will add it.  Until
> then, I omit it.
> 
>

Received on Friday, 26 June 1998 19:12:45 UTC