[Tasks] Spec: follow-up to #449

[SBrandeis]

TODO

This issue lists the remaining tasks following #449

• [x] Ensure the output types of sentence-similarity are emitted by the inference-codegen script
• [x] Packaging/tooling improvements @coyotte508 (#464)
• [ ] Add missing parameters for generate (link)
• [ ] Add TEI parameters to the feature-extraction / text-embedding task
• [x] Proper params and descriptions for depth-estimation https://github.com/huggingface/transformers/issues/28729 (#472)
• [ ] Document specs structure, code generation & design choices
• [x] Ensure output types are not batched (typing the output for a single sample) (#470 )
• [x] Use snake_case in the JSON Schema to match the current APIs format (#470 )
• [x] Use inputs instead of data in the JSON Schema to match current APIs format (#471 )

"Bigger" changes:

• [ ] Rename feature-extraction to text-embedding
• [ ] Unify text-generation and text2text-generation

[Wauplin]

(some comments I had)

• [ ] in "common parameters" I would rename GenerationParameters to TextGenerationParameters or TextGenerationCommonParameters (to differentiate from other image generation (and audio, video, etc?))

"Bigger changes":

• [ ] add constraints to the values (especially text_generation and text_to_image float/integer parameters). Constraints might not be reflected in all generated code but will still be useful to document

[philschmid]

I was looking into the first added schema and was a bit surprised that they do not match the API schema from inference Endpoints or the Inference API. I thought we wanted to create an external schema that can be used for code generation and other validation to make sure all libraries, API, etc have the same types.

When i looked into it i saw that the main input is called "data" and not "inputs". I also noticed that the "parameters" are "camelCase" and not "snake_case" (in the definitions), Some definitions, e.g. "text-generation" are only for TGI and not for the text-generation pipeline.

What's the plan here? I don't think we should maintain definitions that need to be adjusted again to work with our products. I thought we start with an API first approach to then integrate into the libraries.