input profile name limited to ASCII lowercase?

[aphillips]

Proposed comment

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.

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.)

Instructions:

This follows the process at https://w3c.github.io/i18n-activity/guidelines/review-instructions.html

1. Create the review comment you want to propose by replacing the prompts above these instructions, but LEAVE ALL THE INSTRUCTIONS INTACT

2. Add one or more t:... labels. These should use ids from specdev establish a link to that doc.

3. Set a label to identify the spec: this starts with s: followed by the spec's short name. If you are unable to do that, ask a W3C staff contact to help.

4. Ask the i18n WG to review your comment.

5. After discussion with the i18n WG, raise an issue in the repository of the WG that owns the spec. Use the text above these instructions as the starting point for that comment, but add any suggestions that arose from the i18n WG. In the other WG's repo, add an 'i18n-needs-resolution' label to the new issue. If you think any of the participants in layout requirements task force groups would be interested in following the discussion, add also the appropriate i18n-*lreq label(s).

6. Delete the text below that says 'url_for_the_issue_raised', then add in its place the URL for the issue you raised in the other WG's repository. Do NOT remove the initial '§ '. Do NOT use [...](...) notation – you need to delete the placeholder, then paste the URL.

7. Remove the 'pending' label, and add a 'needs-resolution' tag to this tracker issue.

8. If you added an *lreq label, add the label 'spec-type-issue', add the corresponding language label, and a label to indicate the relevant typographic feature(s), eg. 'i:line_breaking'. The latter represent categories related to the Language Enablement Index, and all start with i:.

9. Edit this issue to REMOVE ALL THE INSTRUCTIONS & THE PROPOSED COMMENT, ie. the line below that is '---' and all the text before it to the very start of the issue.

---

This is a tracker issue. Only discuss things here if they are i18n WG internal meta-discussions about the issue. Contribute to the actual discussion at the following link:

§ url_for_the_issue_raised

[xfq]

Related previous comment: immersive-web/webxr#1121