Ralph,
I suspected something like this was our confusion. We use <actuaTerm> in
our solution to display to our users, just like in regular facets (and
yes, <displayTerm> would be a better term for it, I agree with that).
What I am saying is we *do* need something like "last week" (whether you
want to name it <actualTerm> or <displayterm>, as long as it's the
*same* for regular facets and range facets). I am also saying that we do
*not* need something like "lastWeek", as this is also present in <query>
and <requestUrl>. I think "smart" clients would either use
<query>/<requestURL>, or they would be smart enough to remember the
"lastWeek" value. But I am still willing to be convinced otherwise with
a script example.
Edo
>>-----Oorspronkelijk bericht-----
>>Van: LeVan,Ralph [mailto:]
>>Verzonden: woensdag 20 oktober 2010 17:05
>>Aan: Edo Plantinga; Edward C. Zimmermann
>>CC: Ray Denenberg, Library of Congress;
>>
>>Onderwerp: RE: [search-ws-comment]Forms versus Scan and Facet
>>// was: ....
>>
>>Ah, I'm starting to see your confusion!
>>
>><actualTerm> is the value that must be returned to the
>>server. Until now, it was also the form of the term to be
>>displayed to the user. I'm proposing that an explicitly
>>displayable form of the term be returned.
>>
>><actualTerm>, <query> and <requestURL> are overlapping
>>concepts. The value of actualTerm MUST be in the query
>>somewhere and the URL encoded query MUST be in the
>>requestURL. The <query> and <requestURL> elements are
>>provided for thin/stupid clients that can't figure out how to
>>form a query from the original query plus the actualTerm.
>>
>>So, if you ignore <query> and <requestURL> as being
>>redundant, then the <term> element only has one subelement:
>><actualTerm>. I am proposing that we add <displayTerm>.
>>
>>In no way are actualTerm, query or requestURL alternatives to
>>the displayTerm that I am proposing.
>>
>>Ralph
>>
>>> -----Original Message-----
>>> From: Edo Plantinga [mailto:]
>>> Sent: Wednesday, October 20, 2010 9:55 AM
>>> To: LeVan,Ralph; Edward C. Zimmermann
>>> Cc: Ray Denenberg, Library of Congress
>>> Subject: RE: [search-ws-comment]Forms versus Scan and Facet // was:
>>....
>>>
>>> Ralph,
>>> I believe we already *have* two such value fields, namely
>><query> and
>>> <requestUrl>. Since the discussion seems to be getting
>>stuck on this,
>>I
>>> suggest you give an example of a script (in plain English or pseudo
>>> code) that needs the extra value field you suggest, but cannot work
>>with
>>> <query> and <requestURL> alone.
>>>
>>> So what I am suggesting is that we only need these three,
>>and no more:
>>> <actualTerm>Last week</actualTerm> =====> this one's for display
>>to
>>> users
>>> <query>nuthaches AND dc.published=Last week</query> =====> this
>>> one's for computers that need to do some manipulation
>>>
>><requestUrl>http://z3950.loc.gov:7090/voyager?query="nuthaches
>>%20AND%20
>>> d
>>> c.published=Last%20week" </requestUrl> =====> this one's for
>>> computers to use for constructing a hyperlink for a user to
>>click on
>>> (combined with <actualTerm>).
>>>
>>> If you can show me such a script that needs more info than
>>above, I am
>>> happily convinced.
>>>
>>> Edo
>>>
>>>
>>> >>-----Oorspronkelijk bericht-----
>>> >>Van: LeVan,Ralph [mailto:]
>>> >>Verzonden: woensdag 20 oktober 2010 15:13
>>> >>Aan: Edward C. Zimmermann; Edo Plantinga
>>> >>CC: Ray Denenberg, Library of Congress; Robert van de Rijt
>>> >>Onderwerp: RE: [search-ws-comment]Forms versus Scan and Facet //
>>> >>was: ....
>>> >>
>>> >>In XForms, items in select lists have both labels and values.
>>> >> They clearly see a need to display one thing to the user
>>and return
>>> >>something completely different to the server. I continue
>>to claim
>>> >>that this is a parallel functionality.
>>> >>
>>> >>Ralph
>>> >>
>>> >>> -----Original Message-----
>>> >>> From: Edward C. Zimmermann [mailto:]
>>> >>> Sent: Wednesday, October 20, 2010 4:21 AM
>>> >>> To: Edo Plantinga; LeVan,Ralph
>>> >>> Cc: Ray Denenberg, Library of Congress; Robert van de Rijt
>>> >>> Subject: RE: [search-ws-comment]Forms versus Scan and Facet //
>>was:
>>> >>....
>>> >>>
>>> >>> HTML Forms:
>>> >>>
>>> >>> In XForms we have labels and variables:
>>> >>>
>>> >>> <input ref="fname"><label>First Name</label></input>
>>> >>>
>>> >>> The First Name is what is displayed and in XForms the
>>elements get
>>> >>jammed
>>> >>> into
>>> >>> a template.. filling the tags: here fname
>>> >>>
>>> >>> This can be also a path:
>>> >>> <input ref="/my:person/my:fname"> etc..
>>> >>>
>>> >>> Because of this in XForms ***every*** input must have a label
>>> >>(***mandatory
>>> >>> element***).
>>> >>>
>>> >>> Just on the basis of naming we have this problem given the
>>> >>restrictions on
>>> >>> element names (can't start with a number, no spaces, etc.)
>>> >>>
>>> >>>
>>> >>> Scan/Facet:
>>> >>>
>>> >>> Is the DisplayTerm really analogous in its need to label?
>>> >>The term is
>>> >>not a
>>> >>> structural element to be filled.
>>> >>>
>>> >>> Getting back a term from a last name field "Zimmermann".
>>> >>Zimmermann is
>>> >>not a
>>> >>> tag but rather, looking at forms, the content of an
>>> >>element. There are
>>> >>no
>>> >>> restrictions on what the Term sub-elements (Display etc.)
>>> >>can contain.
>>> >>>
>>> >>> I think we can all live quite well without a
>>DisplayTerm (thinking
>>> >>Forms:
>>> >>> label) in Scan. With our "anything goes" approach in Facet as
>>well..
>>> >>>
>>> >>> And my idea for some kind of verbose "Description"--- not like
>>label
>>> >>in XForms
>>> >>> but more like help and hint--- for a facet element? Here I see
>>some
>>> >>business
>>> >>> cases in a number of applications including ecommerce/shops (one
>>of
>>> >>the
>>> >>> applications where Facets is king).
>>> >>>
>>> >>>
>>> >>> --
>>> >>>
>>> >>> Edward C. Zimmermann, NONMONOTONIC LAB Basis Systeme
>>> netzwerk,
>>> >>> Munich Ges. des buergerl. Rechts Office Leo (R&D):
>>> >>> Leopoldstrasse 53-55, D-80802 Munich,
>>> >>> Federal Republic of Germany
>>> >>> http://www.nonmonotonic.net
>>> >>> Umsatz-St-ID: DE130492967
>>> >>>
>>> >>
>>> >>
>>> >>
>>
>>
>>
