input profile name limited to ASCII lowercase?

[aphillips]

10.1 XRInputSource https://www.w3.org/TR/webxr/#xrinputsource-interface

An input profile name is an ASCII lowercase DOMString containing no spaces, with separate words concatenated with a hyphen (-) character. A descriptive name should be chosen, using the prefered verbiage of the device vendor when possible. If the platform provides an appropriate identifier, such as a USB vendor and product ID, it MAY be used. Values that uniquely identify a single device, such as serial numbers, MUST NOT be used. The input profile name MUST NOT contain an indication of device handedness. If multiple user agents expose the same device, they SHOULD make an effort to report the same input profile name. The WebXR Input Profiles Registry is the recommended location for managing input profile names.

It's not clear why profile names are limited to ASCII. It appears that the name exposed might be visible to users and intended for at least partial human consumption (users might choose which profile to use??). Is there a meaningful way to wrap these with (localizable) human-friendly names? This sort of human interaction is later implied by:

This may include a more generic or prior version of the device, a more widely recognized device that is sufficiently similar, or a broad description of the device type (such as "generic-trigger-touchpad").

It's understandable that localization of profiles presents a practical problem, in that the internal name should be limited and deterministic for the profile. However, understanding the generated profile names depends on a knowledge of English.

I18N recognizes that most of the names in WebXR--including these--are intended to be program internal, in which case an ASCII or ASCII-lowercase restriction is entirely appropriate. But once such names become exposed as interface, the restriction becomes an issue.

Note: It is good that the names are presented in a machine-defined order (descending specificity).

(Note the typo for the word "preferred" in the second sentence.)

[AdaRoseCannon]

The generic names are specifically for mapping to the generic controller models when the device specific profile string doesn't have a matching one.

For example see the generic devices on this page: https://immersive-web.github.io/webxr-input-profiles/packages/viewer/dist/index.html

Each profile string which doesn't match to a profile are likely to result in an additional network connection. There is also the XRInput.gamepad.id which is probably closer to the information you would want to expose to the user to describe the human consumable name of the connected controller.

[AdaRoseCannon]

Sorry for briefly closing I fumbled the keyboard (why is there a shortcut for that?!)

[aphillips]

@AdaRoseCannon Thanks for the comment.

I think the demo page you linked is a good illustration of the potential problem. The profile names on the page are accessible to users because the page (and the names) are in English. The English words used in the profile identifiers tells me what to expect from each item in the drop down.

To be clear, WebXR doesn't have to specify the localization mechanism per-se, but maybe there should at least be a note that implementations should provide one.

[Manishearth]

I think the demo page you linked is a good illustration of the potential problem. The profile names on the page are accessible to users because the page (and the names) are in English

The demo page is specifically for playing around with the specification, I don't see that as an example of a typical pattern seen in code. For your typical user, there will be a library that knows about these identifiers, and their XR session will expose a set of identifiers in preference order, and the library will match up with the first known one. It's internal.

I think that demo page is similar to the Unicode languageidentifier test page in spirit: exposes something that is ASCII-only to the user specifically so that people can play around with an otherwise internal identifier. The Unicode languageidentifier test page is not an example of a usage pattern that is expected to be found in the wild around BCP-47 identifiers.

[aphillips]

@Manishearth No disagreement. I just want to make the group aware of the potential for this kind of leakage. It's a Good Thing to make identifiers somewhat human readable (developers have to debug stuff and opaque identifiers are a PITA in that context). As long as it is internal, you can mark this as addressed, although I would suggest a note about not showing IDs to users. If that feels intrusive, consider having a one paragraph Internationalization Considerations section.