Stongly-typed parameters

[Lorenzo Bigagli]

Hi,

I have added a discussion page to the OpenSearch Parameter extension with a proposal for a mechanism supporting strongly-typed parameters (see also https://groups.google.com/d/topic/opensearch/p5Q1u8skHrg/discussion, where XForms was suggested).
I understand that this forum is preferable for such discussions, so I copy it here below:

I would propose an additional "type" attribute to the "Parameter" element, to support strong(er) typing by compliant clients.

The attribute would be optional, and its values could be the simple types built in to XML Schema (e.g. string, decimal; see XML Schema Part 0: Primer, §2.3, Table 2).

Compliant clients may exploit the type information to adapt the input control to the expected input type, to populate the template.

For example, in case of a template containing a parameter of type date, a browser may present the user with a calendar widget.

I would be interested in opinions and alternatives on that.
Regards,
 LB

[Pedro Gonçalves]

 isn't the type of the parameter implicit in the template value?

for instance, you mention the type date example, for this you should define an extension like the one in time:start 

<Parameter name="start_date" value="{time:start}" minimum="0" />

the type and format of the parameter are defined in the extension specification.

if we allow dual parameter we might end with misleading and conflicting information that might override the original parameter definition 

you could define a new extension with the desire types but also that might be misleading due to the strong emphasis in in opensearch to the content/meaning of the parameter not the type (time:start versus time:value) 

cheers

Pedro  

--
You received this message because you are subscribed to the Google Groups "OpenSearch" group.
To post to this group, send email to opens...@googlegroups.com.
To unsubscribe from this group, send email to opensearch+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/opensearch?hl=en.

[Lorenzo Bigagli]

I would agree that the type of the parameter is implicit in the
template value _when using well known extensions_ (as long as an
extension specifies type and/or format of its parameters).

Explicit type definition would support generic custom parameters, like
in:
<Parameter name="birthday" value="{my:birthday}" type="xsd:date" />

Another point to discuss/clarify: why is the value attribute optional
in the Parameter extension?
I can't think of any case when it can be missing.

Cheers,
Lorenzo

On 14 Mar, 12:30, Pedro Gonçalves <pereira.goncal...@gmail.com> wrote:
>  isn't the type of the parameter implicit in the template value?
> for instance, you mention the type date example, for this you should define an extension like the one in time:start
> <Parameter name="start_date" value="{time:start}" minimum="0" />
> the type and format of the parameter are defined in the extension specification.
> if we allow dual parameter we might end with misleading and conflicting information that might override the original parameter definition
>
> you could define a new extension with the desire types but also that might be misleading due to the strong emphasis in in opensearch to the content/meaning of the parameter not the type (time:start versus time:value)
>
> cheers
>
> Pedro  
>
> On Mar 14, 2011, at 11:47 AM, Lorenzo Bigagli wrote:
>
> > Hi,
>

> > I have added a discussion page to the OpenSearch Parameter extension with a proposal for a mechanism supporting strongly-typed parameters (see alsohttps://groups.google.com/d/topic/opensearch/p5Q1u8skHrg/discussion, where XForms was suggested).

[Pedro Gonçalves]

i'd suppose that the "my" namespace defines what are the valid formats for the birthday parameter
if a client doesn't know the namespace then it has to discard it

one thing that might be useful for future work is a way to formalize the parameters (something like ngRELAX ? ) in the different namespaces

regarding the optionally I think you raise a good concern, like you I don't see any case when that could happen

ciao
pedro

[Tim Williams]

Hi Lorenzo,
In the question that you reference above by "constrain the input", I
didn't mean by 'typing' - rather, I meant by the potential values. I
can see that both are useful though. Specifically, I need to be able
to have an enumeration that can change at runtime, for example, a list
of searchable "countries" or a list of searchable "categories". This
list is very quiet and I'm not sure what the process is for pushing
through change requests like this - perhaps we should start by
figuring that out?

Thanks,
--tim