Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sorting nodes alphabetically is underspecified #598

Open
aphillips opened this issue Sep 21, 2018 · 5 comments

Comments

Projects
None yet
4 participants
@aphillips
Copy link
Contributor

commented Sep 21, 2018

1.24. The MediaStreamAudioSourceNode Interface
https://www.w3.org/TR/2018/CR-webaudio-20180918/#mediastreamaudiosourcenode

This interface represents an audio source from a MediaStream. The track that will be
used as the source of audio and will be output from this node is the first MediaStreamTrack
whose kind attribute has the value "audio", when alphabetically sorting the tracks of
this MediaStream by their id attribute.

Sorting alphabetically seems to be underspecified. Given that MediaStreamTrack id attributes are recommended to be UUIDs and that the "alphabetic" sorting appears to be an arbitrary way to prioritize the item selection, defining the comparison as ASCII case-insensitive might be a good choice. However, since there is no actual restriction on what the values can be, I'd suggest that you replace "alphabetically" with ordering by code point (which means that it is case-sensitive, please note)


WHEN CREATING A NEW ISSUE DO SO ABOVE THIS PARAGRAPH, REPLACING THE PROMPTS, BUT LEAVE THIS PARAGRAPH INTACT AS WELL AS THE TEXT BELOW IT When this issue is raised in the github/bugzilla/mail of the WG that owns the spec, use the text above this para as the basis for that comment. Then edit this issue to remove this paragraph and ALL THE TEXT ABOVE IT. Replace the text 'link_to_issue_raised' below with a link to the place you raised the issue, but leave the remaining text below this para unaltered.

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:

§ link_to_issue_raised

@svgeesus

This comment has been minimized.

Copy link

commented Sep 27, 2018

Thanks for your comment. We discussed it on todays telcon. We agree that "alphabetically" is imprecise and that we should order by Unicode codepoint. We are not yet sure on whether to do case folding, but suspect that this is indeed a good idea.

RFC 4122 section 3 requires that the characters to be generated in lower case, while being case insensitive on input, though some commonly-used implementations violate this rule.
https://en.wikipedia.org/wiki/Universally_unique_identifier

So these are 128bit numbers represented to users (and input) as hex strings and thus, constrained to US-ASCII.

Given the RFC recommends converting to lowercase on input, and as in practice implementations don't all do that, ASCII case-insensitive (as used by for example CSS) seems like an appropriate method.

@stpeter

This comment has been minimized.

Copy link

commented Sep 27, 2018

@svgeesus A small note: the Media Capture and Streams spec says only that "A good practice is to use a UUID [rfc4122], which is 36 characters long in its canonical form" (this is not even a SHOULD), thus the concern about id values that are not UUIDs in the first place (basically it's just a DOMString).

@aphillips

This comment has been minimized.

Copy link
Contributor Author

commented Sep 29, 2018

@svgeesus Thanks for the reply. Adding casefolding adds a level of complexity that you might not want, since it generally brings with it the need to do text normalization or the need to case fold only ASCII characters. My personal suggestion would be to do strict Unicode code point ordering, since the goal of the sort doesn't appear to be to produce any specific order.

@stpeter is right that the id value can be any DOMString, at least technically. But the original text commented appears to be providing a deterministic way of choosing arbitrarily when there is more than one audio item. Either ASCII or Unicode case insensitive comparison requires more plumbing than is needed to do that (there is a tiny bias in favor of implementations that use uppercase in UUIDs, but not enough to make it worth the effort??)

@r12a

This comment has been minimized.

Copy link
Contributor

commented Oct 1, 2018

Chaps, this is not the place to hold this discussion since the Web Audio Working Group doesn't see it. (@svgeesus see the notes in the first comment: you intercepted our tracker issue before we had sent you the comment officially :-).) Addison, when you raise the issue in the target WG issue list could you copy over relevant comments there?

@stpeter

This comment has been minimized.

Copy link

commented Oct 1, 2018

@r12a Noted!

@aphillips For the comments in the Web Audio WG tracker: if the spec said MUST be a UUID I'd have no concerns.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.