== Session identification ==
* The schema defines `editingSessionId` as "a string of 32 alphanumeric characters, unique to the current page view session; used for grouping events".
** [mw.user](https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.user) provides a number of different methods for generating session IDs.
** MobileFrontend [uses sessionId()](https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/304c176f291b68dd300448d12d7133236ec5c8cc/resources/mobile.startup/user.js#L64).
** The visual editor [uses generateRandomSessionId()](https://github.com/wikimedia/mediawiki-extensions-VisualEditor/blob/4a41a1aa4c6c98465bf4818ed8b8dad621c2712f/modules/ve-mw/init/ve.init.mw.trackSubscriber.js#L20)
** The 2010 wikitext editor [uses MWCryptRand::generateHex(32)](https://github.com/wikimedia/mediawiki-extensions-WikiEditor/blob/38a70500a0d26f10e32df0ed8924f4c10277e3f6/includes/WikiEditorHooks.php#L270).
* Our current implementation of editing sessions is tightly coupled to a page view. However, this doesn't map very well to what we think of as a single edit session: on desktop, switching between the visual editor and the wikitext editor while retaining changes causes a new page view, while on MobileFrontend, aborting an edit using the back button and then reopening the editor (which doesn't preserve your changes) all happens in one page view.
* We don't use the core EventLogging code for client-side session token generation and sampling.
* The new ability to switch back-and-forth between the visual editor and wikitext invalidates some key assumptions (for example, we probably want to update `action.init.mechanism`)
* How should we account for "micro-editing experiences" like Flow? Should they be included in this schema at all?
* Even with T124676 resolved, the table is still quite large. Consider whether to drop mostly unused fields like `page.title` or normalize the schema (T123958)
* Do our `action.saveFailure.type` values cover all the options?
** For example, T197499 deals with a save failure because the wiki is in read-only mode, which isn't covered.
* Problems with hive refinement (T202348)
* Does it make sense to have one schema that covers all our interfaces?