10 messages in org.oasis-open.lists.search-ws-commentRE: [search-ws-comment]Forms versus S...| From | Sent On | Attachments |
|---|---|---|
| LeVan,Ralph | Oct 20, 2010 8:04 am | |
| Edo Plantinga | Oct 20, 2010 8:29 am | |
| LeVan,Ralph | Oct 20, 2010 8:54 am | |
| Edward C. Zimmermann | Oct 21, 2010 5:40 am | |
| Edo Plantinga | Oct 21, 2010 6:39 am | |
| LeVan,Ralph | Oct 21, 2010 8:21 am | |
| LeVan,Ralph | Oct 21, 2010 8:25 am | |
| Edward C. Zimmermann | Oct 21, 2010 9:11 am | |
| LeVan,Ralph | Oct 21, 2010 10:33 am | |
| Edward C. Zimmermann | Oct 21, 2010 12:10 pm |
| Subject: | RE: [search-ws-comment]Forms versus Scan and Facet // was: .... | |
|---|---|---|
| From: | LeVan,Ralph (lev...@oclc.org) | |
| Date: | Oct 20, 2010 8:04:39 am | |
| List: | org.oasis-open.lists.search-ws-comment | |
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:Edo....@ictu.nl] 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:lev...@oclc.org] 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:ed...@nonmonotonic.net] 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
-- This publicly archived list offers a means to provide input to the OASIS Search Web Services TC.
In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting.
Subscribe: sear...@lists.oasis-open.org Unsubscribe: sear...@lists.oasis-open.org List help: sear...@lists.oasis-open.org List archive: http://lists.oasis-open.org/archives/search-ws-comment/ Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines: http://www.oasis-open.org/maillists/guidelines.php Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=search-ws Join OASIS: http://www.oasis-open.org/join/