14:18 | <littledan> | In the TC39 Tools outreach call, we're looking into improvements to source maps. Maybe they should eventually be standardized in TC39? We're discussing this in #source-maps:matrix.org and collaborating in GItHub, e.g., some initial shared goals are at https://github.com/source-map/source-map-rfc/issues/22 . Please join us if you're interested! |
20:16 | <Michael Ficarra> | Can't TC39 only work on Ecma documents? Are you suggesting that Ecma should adopt the source map spec? |
20:18 | <littledan> | Yes |
20:18 | <littledan> | This is the question I would like input on: Should TC39 and therefore obviously Ecma take on this sort of work? |
20:20 | <littledan> | I think TC39 is a good place because we assemble a lot of relevant stakeholders, and because we have good IPR protections. But if the committee says no, there are lots of other possible paths. |
20:20 | <littledan> | I imagine source maps would be a separate document though |
20:41 | <bakkot> | I tend to see the formal standards process as something to be adopted only as a last resort if necessary to allow companies to coordinate on tasks that might have IP or antitrust implications. If the potential contributors / users of a spec are able to cooperate without needing the aegis of an actual standards body that's going to be better. |
20:42 | <bakkot> | For source maps, is there a concern about IP/antitrust? |
20:48 | <Chris de Almeida> | there are always concerns about IP/antitrust |
20:48 | <littledan> | I think it is reasonable to be concerned about IP for all sorts of technical artifacts like this. (I have no understanding of what antitrust is supposed to mean in a standards universe where WHATWG is apparently kosher.) The community shares an interest in having a solid written description, test cases, and process for continuing changes. I think TC39, or likely a TG4 of it, would provide a good context for this. If TC39 says no, I would encourage the community to start in WICG and then figuring out details later. |
20:49 | <Chris de Almeida> | and not having it under the auspices of a standards body can make it difficult or impossible for employees of large companies to contribute |
20:50 | <littledan> | It is a common pattern in the web world to initially not bother with standards and then realize they are essential, see console, WebDriver, WebExtensions, … |
20:51 | <littledan> | We live in a world of social constructs where the perceived legitimacy of a standards context acts as a culturally defined glue that encourages everyone to cooperate. TC39 can decide whether to invest its legitimacy in this project. |
22:24 | <Michael Ficarra> | who currently owns the IP for the source maps spec? Mozilla? |
22:24 | <Michael Ficarra> | they would have to assign it to Ecma, right? |
22:28 | <littledan> | License, not assign |
22:28 | <Michael Ficarra> | sure |
22:28 | <Michael Ficarra> | but is it Mozilla? |
22:29 | <littledan> | This is an advantage of working within an established standards organization that everyone who owns the relevant IP is already part of |
22:29 | <littledan> | I think Google would have more of a claim to the current version but I would need to check |
22:31 | <Michael Ficarra> | does Ecma have experience adopting existing works with mixed provenance? I would assume so |
22:31 | <littledan> | Well… JS is one of those things |
22:32 | <littledan> | But apart from that, if the IP is owned by member companies, the act of standardizing it will cause the licenses to trigger |
22:35 | <littledan> | So far, I haven’t seen Ecma support TC39 with IPR infrastructure the way the W3C has. They sort of defer to us there. So I don’t think we will find pushback on the Ecma side, but I can float this at the upcoming ExeCom meeting to ferret out concerns if you think that it’s a good idea (arguably that would be out of order though; I was planning to raise it to committee first) |
23:03 | <Michael Ficarra> | I think it's pretty appropriate for TC39 to adopt it, considering the cross-cutting concerns |
23:04 | <Michael Ficarra> | so I personally would support it |
23:04 | <littledan> | It is important that source maps stay multilingual, but they are likely to grow some more JS-specific features |
23:04 | <littledan> | or at least make design decisions informed by JS, for sure |
23:05 | <Michael Ficarra> | yes, we have an interest in ensuring that they remain a good fit for JS and JS developers' needs |
23:05 | <littledan> | Some parts may have web tie-ins too, e.g., one of the problems with source maps is that it's ambiguous how the url is interpreted. |