Re: Questions about HTTP/V1.0 doc dated 14-Jul-93
Fred Williams (fwilliam@ccs.carleton.ca)
Mon, 16 Aug 93 20:58:46 EDT
Dave_Raggett writes:
>
> Fred Williams says:
>
> > 3) An earlier document on HTTP describes the TEXTSEARCH method to request a
> > search to be done utilizing search information contained in the data
> > section. Since the data section is in MIME this would allow complex
> > searches to be done and searches done on information other than ASCII
> > text. The latest document seems to degrade method TEXTSEARCH to only a
> > server response to indicate that searching is possible. One then uses
> > the GET method ( ie ?xxx+yyy ... ) to perform the actual search. This
> > does now restrict the search capabilities to only ASCII and simple
> > searches.(ie 'very' limited pattern matching and no boolean operators ).
> > Is it now intended to keep TEXTSEARCH only as a response ( ie
> > duplicating [ISINDEX] functionality) or to return its functionality as
> > a request method.
>
> I am very interested in clarifying the spec for search strings as I see it
> as being an enabler for the forms that can be specified with HTML+.
>
> In an earlier message I suggested taking advantage of the special characters
> permitted in search strings to specify attribute value pairs and boolean
> operators. (see http://info.cern.ch/hypertext/WWW/Addressing/BNF.html)
> What we need now is some guidelines for this to be included in the HTRQ spec.
>
> The following lists the special chars along with suggested roles:
>
> $ Prefix for variable names
> _ Used as ordinary char in identifiers
> @ Infix operator as in attribute@value
> ! Logical negation
> % For escaping other characters e.g. %20 for the space char.
> ^ Logical disjunction
> & Logical conjunction
> * Not sure what to use this for ...
> ( Left bracket for grouping things
> ) Right bracket for grouping things
> . Decimal point in numbers or period in text.
>
> It would be very useful to also allow:
>
> , minor separator
> ; major separator
>
> These are needed for sending lists of points, as in the ismap mechanism for
> IMG. Are there any problems in extending the definition of "xalpha" Tim?
>
> Any comments?
>
> Dave Raggett
>
This still does not allow for questions like `is
this image part of another' or `is this audio segment contained in
this document'. Now this may seem that these requests
may be a little out of the ordinary however I feel that the definition
of HTTP/V1.0 should not restrict these types of searches. If, as
suggested, the TEXTSEARCH ( which should be renamed SEARCH ) is
implemented as a request method, utilizing the data portion of the
request to define the search, there would be no restrictions on the
searching capabilities of HTTP/V1.0. It would be entirely up to the
client and server capabilities.
Fred Williams
fwilliam@ccs.carleton.ca