Why is ml a member of Navigator?

[bathos]

Is there a specific motivation for this? There could be a good reason for it that I’m not seeing, but on the surface it appears misguided for it not to be a member of the global interface. Quoting @domenic from that thread:

Guidance like this [global “pollution” avoidance] often leads people to putting their functions under document or navigator, when they have nothing to do with Documents or with user agent data. I've personally had to advise several teams to move away from such designs in their proposals. (navigator is particularly polluted these days, unfortunately. A design principle discouraging such pollution, and encouraging using the global object instead, would be great!)

[anssiko]

Thanks for this question! The WG discussed this design consideration first when the work started and decided at that time to follow the convention set by other similar APIs being developed in parallel to this effort such as WebGPU. I think that was the key motivation. Furthermore. at that time there was no authoritative guidance on this so the WG had to look around to other similar APIs for inspiration.

Other WG participants are free to chime in if they have a different perspective or additional context.

That said, I'm pleased to see discussion on this design principle re-emerge in the issue you referred to. I believe future API authors would benefit from clearer guidance for this consideration. Should a principle have been in place for this when this API was first conceived the WG would have benefited from it.

@bathos, please let us know if you have any additional questions and feel free to close this issue if it addressed your question satisfactorily.

[bathos]

I didn’t realize this was already at the candidate recommendation level. I don’t know the W3C maturity system well, but the past tense in the reply suggests this means it’s too late to address even though Chromium/Blink has (afaict) the only implementation. Thanks.

[zolkis]

@bathos what would be your preferred solution? Constructor for the ML object?
Its main function is to host the factory methods to create MLContext objects, to which the rest of the API is anchored.

[bathos]

@zolkis I don’t know enough about the API to answer confidently and am not an authority on this, but by appearances, the ML interface (with its singleton instance exposed as navigator.ml) looks like the ML namespace (which would be exposed as ML) in disguise. Seemingly comparable examples are CSS and WebAssembly.

- interface mixin NavigatorML {
-   [SecureContext, SameObject] readonly attribute ML ml;
- };
- Navigator includes NavigatorML;
- WorkerNavigator includes NavigatorML;

/* ... */

[SecureContext, Exposed=(Window, DedicatedWorker)]
- interface ML {
+ namespace ML {
  Promise<MLContext> createContext(optional MLContextOptions options = {});
  Promise<MLContext> createContext(GPUDevice gpuDevice);

  [Exposed=(DedicatedWorker)]
  MLContext createContextSync(optional MLContextOptions options = {});
  [Exposed=(DedicatedWorker)]
  MLContext createContextSync(GPUDevice gpuDevice);
};

An example usage like navigator.ml.createContextSync() would instead be written ML.createContextSync().

[zolkis]

@bathos: I agree, I've been using/preferring namespaces as well in other specs.

Thanks for the input. Feel free to comment the spec from the p.o.v. of modern idioms: the web platform is evolving, and it's good to keep in sync. It is up to the spec editors to consider the suggestions.