[Tasks] Spec: follow-up to #449

[SBrandeis]

TODO

This issue lists the remaining tasks following #449

• Ensure the output types of sentence-similarity are emitted by the inference-codegen script
• Packaging/tooling improvements @coyotte508 (👷 Changes to build inference types #464)
• Add missing parameters for generate (link)
• Add TEI parameters to the feature-extraction / text-embedding task
• Proper params and descriptions for depth-estimation Depth Estimation Pipeline docstrings are wrong transformers#28729 (🩹 [Tasks] Fix depth-estimation spec #472)
• Document specs structure, code generation & design choices
• Ensure output types are not batched (typing the output for a single sample) (♻️ [Tasks] Use snake_case for parameters (+ misc format fixes) #470 )
• Use snake_case in the JSON Schema to match the current APIs format (♻️ [Tasks] Use snake_case for parameters (+ misc format fixes) #470 )
• Use inputs instead of data in the JSON Schema to match current APIs format (♻️ [ Tasks] Rename data -> inputs to conform existing APIs #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.