[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [search-ws-comment]Forms versus Scan and Facet // was: ....
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:levan@oclc.org] >>Verzonden: woensdag 20 oktober 2010 17:05 >>Aan: Edo Plantinga; Edward C. Zimmermann >>CC: Ray Denenberg, Library of Congress; >>search-ws-comment@lists.oasis-open.org >>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:Edo.Plantinga@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:levan@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:edz@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 >>> >>> >>> >> >>> >> >>> >> >> >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]