clarifications to abstract, introduction and problem statement

[dadahl]

from Jon Stine

• There appeared to me an implicit hypothesis running through the abstract, introduction, and problem statement, one that sounded like this: the path to interoperability will be created through several steps of standardization, beginning with the standardization of IPA components.
o If this is correct, should we  Say, in the abstract, that we are exploring the potential for architectural/component standardization as one of a multi-step means to interoperability?  Provide, in the introduction, an operative definition of interoperability – one that is explored deeper in the paper in the explanation of the Provider Selection Service? • And provide, with reference to Debbie’s great “benefits of standards” work, brief commentary as to the multiple benefits of IPA interoperability, especially of the three types outlined on pp’s 10 ff.  Provide, in the introduction, a high-level roadmap toward interoperability, one that could look like: • Identification and standardization of IPA components -> Identification and standardization of dialog interfaces -> X -> Y -> Z?

[schnelle]

First point is already addressed in section 1 This document is a first step in our strategy for IPA standardization. It describes a general architecture of IPAs and explores the potential areas for standardization.

[schnelle]

Point 2 not needed as detailed later in the document Point 3 not needed as it seems to be moarketing driven Point 4 not needed as this goes beyond the purpose of the document