I think I understand NG9-1-1 data flow fairly well, and I have NO IDEA what this ISF is intended to accomplish. There is no example, no hint of where existing standards are deficient and no information needed to create a charter which would not completely overlap with existing work.
Some specifics: "The transition of data from legacy ALI structures to NG9-1-1 effective result", whatever "effective result" might be, is duplicative of Appendix A of STA-010 which expressly calls out how legacy data structures are carried in NG9-1-1 elements and the text of NG9-1-1 shows how the new elements are used.
"the addition of new data (either produced initially on a call or provided as additional data) to the PSAP display" is a user interface issue which is a very poor subject for any kind of standard, and based on my experience, committees do terrible jobs; truley horrible, in attempting to guide UI design, especially in the absence of any good examples. NENA should stay out of guidance on UI design. Whatever you decide is good is sure to be bad in an excelleny UI. NENA has no expertise in UI. It has no experience in creating good UI guidance.
"the PIDF-LO data element to PSAP screen data relationships" is more UI, and even better example of where I believe NENA should not attempt guidance. This is a very complex issue, for which everyone has limited experience, and thus no basis to make recommendations. It surely is something that expressly should not be standardized, or even harmonized, as it depends so much on context, the state of a PSAP's GIS system, and the specifics of how a call is handled in a given implementation.
"the conversion of legacy CoS indicators to the new NG9-1-1 definitions" is a misnomer. There is no conversion other than some obvious mapping if service providers refuse to actually deliver what the standard says. The mechanisms that replace CoS in NG9-1-1 are fundamentally different, and "conversion" isn't the issue. I think the documentation in the RFCs are sufficiently clear that any service provider can readily determine what the proper values are. I could see some value in creating some examples of real services and showing how they would be represented in the Additional Data mechanisms. Note that this has nothing to do with NGCS or PSAP implementations, but only what values are put into the fields by the orginating network. If that's in scope, the ISF is unclear about that.
"and the transition from legacy approaches (VPC or MPC/GMLC) to a more integrated data process in NG9-1-1" is beyond what NENA can do. ATIS, CableLabs and 3GPP are the proper venues for that. It's also pretty straightforward. I could see some further development of the NGTPC documents to advise some strategies. I would note that this area is something where regulation has huge impact. I'd rather see us work harder on getting ISP requirements to provide LISs than any transition details that are pretty reasonably done now.
"The expected outcome would be a Standard(s) and/or other documents that would clearly define recommended structure and content of data to be provided to the PSAP (or alternate point) under NG9-1-1 operations" The structure and content of the data is completely specified already. Presentation of that standardized structre and content may not be, and shouldn't be. None of the work implied by the statements above this hint at any standards work - the data structures are already standardized and conversion is largely specified.
"and the expansion for other data items from PIDF-LO, multi-media, and other sources can be accomplished utilizing NEIM-compliant schemas" has already been done. The EIDD provides NIEM compliant structures for all the data (some of the data is imported using a NIEM approved wrapper mechanism).