OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws-comment message

[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: ....


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]