Catalog documentation is not in sync with the code

[singlis]

Issue

Our documentation hierarchy is not in sync with our code catalogs. For example, if you look at our Binary Classification Catalog:
https://docs.microsoft.com/en-us/dotnet/api/microsoft.ml.binaryclassificationcatalog?view=ml-dotnet

It contains a Methods and Properties Links. If you drop down Properties, there is a Trainers but that page is fairly empty:
https://docs.microsoft.com/en-us/dotnet/api/microsoft.ml.binaryclassificationcatalog.trainers?view=ml-dotnet

If you look in other catalogs, you will eventually find the Binary Classification Trainers -- for example, LightGBM is located under LightGBM Extensions:
https://docs.microsoft.com/en-us/dotnet/api/microsoft.ml.lightgbmextensions.lightgbm?view=ml-dotnet

However, this does not match what a user would see in code as you can type:
mlContext.BinaryClassification.Trainers.LightGBM

The expectation is that a user should be able to navigate the API Catalog and view all of the functions under that catalog.

More info

It looks like the documentation tool is using the class name to determine the location of where the APIs are located:

machinelearning/src/Microsoft.ML.LightGbm/LightGbmCatalog.cs

Line 14 in 3663320

public static class LightGbmExtensions

Maybe there is a way we can override what the tool is using through an attribute?

[shmoradims]

mlContext.BinaryClassification.Trainers.LightGBM is class.property.property.apiMethod.

The API reference documentation unit is a class so the access path in docs has a few more levels for properties (bold): class -> property -> property type class -> property -> property type class -> apiMethod.

How do you suggest changing that?

[shmoradims]

As I explained above, the API reference pages just follow the structure of ML.NET classes. They can only be as good as ML.NET class hierarchy. This multiple levels of clicking around before getting to the actual content, is a side-effect of the extra intermediate classes required by MLContext architecture, i.e. catalog classes and classes for collection of extension methods (also discussed in #3160). Unfortunately, there's not much we can do here.