> 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