Clarify "best practice" for documenting params in a URITemplate or a Model

[inadarei]

Per #19 there are two ways or creating equivalent of HTML Forms in UBER:

1. URITemplates with action="read" is similar to HTML Form with method=GET
2. Models with action="append" is similar to HTML Forms with method=POST

For the applications that are user-facing, it is often useful the API to provide hints for construction of the user interface (e.g. actual rendered forms). Such hints may include:

1. Labels for the parameter fields
2. Help tips/long-ish field descriptions
3. Input types: multi-select, single-line text, multi-line text etc.

Should UBER provide any guidance for the best-practice of implementing such things? If, yes - what should it be?

[benhamill]

There's been some discussion of this previously. #10 is @mamund's proposed solution. Here's a thread from the email list that has some earlier discussion of the topic.

[mamund]

i think the idea of a description or prompt or label property for the data element makes sense ( @inadarei has this on the bug list, right?).

i think you can implement multi-select and options using properly-marked nested +data+ elements -- we'll need to explore that a bit through some working examples, IMO.

what i'd like to see is some running code on these items. before spec'ing -- let's get some working providers/consumer examples up and running.