Considerations for Future XML Development Methodologies Steve Margenau

1. Considerations for Future XML Development Methodologies Steve Margenau Chair, PESC Technical Advisory Board Systems Analyst, Great Lakes Educational Loan Services

2. We can’t talk about where we’re going in the future without describing how we got where we are.

3. Early 2001 The Core Components Workgroup The Technology Workgroup

4. The Technology Workgroup Weekly calls selecting Best Practices for the Higher Education community Provided advisory and instructional services to the Core Components workgroup as well as to other PESC members

5. Early 2002 The Technology Workgroup Technical Specifications The Core Components Workgroup Data Dictionary An Enthusiastic Membership

6. But what are we going to do? No one was going to change all of their systems to match the PESC definitions. How are we going to support community-wide data items that have the same name, but which must have differences in their definitions, until the time all members migrate to the common definition?

7. At a PESC meeting at the University of Miami in February of 2002 We referenced a whitepaper prepared for PESC in March of 2001, in which an architecture of multiple schemas and namespaces was described that could solve the very issue we were faced with. This architecture was tested, implemented, and is in use to this day.

8. We developed a “Core” schema that contains element definitions that have no differences across PESC members. We developed “Sector” schemas that contain element definitions that are specific to a given sector of the higher education community. Application schemas choose which definition they use by Importing the schema and namespace in which the definition resides, and using the namespace prefix when specifying the element definition.

9. This architecture is easy for people to understand, and works perfectly from an XML definitions perspective. But we now know that it’s not the best approach from an applications and systems environment perspective. Here is why……………………

10. Sector 1 Sector 2 Core First Name Middle Initial Last Name Last Name First Name Middle Initial

11. Sector 1 Sector 2 Core First Name Middle Initial Last Name Last Name First Name Middle Initial

12. The Technical Advisory Board has been working on moving away from this structure for the past year. How do we do this? By hand? This means managing the XML definitions for individual elements, both simple and complex, and putting them together to create schemas - and managing versions of all of them. Then send the schemas out for multiple reviews to be sure we’ve got it right. Will this work? I don’t think so. Our most experienced PESC Schema Author tried this as an experiment. It got real tedious real fast.

13. Once this alternative was turned down, we thrashed for quite awhile. What to do? At our January face-to-face meeting a member of the Technical Advisory Board mentioned a tool his company was evaluating for managing their internal XML components. Our interest was piqued. Are there tools available to make managing components and building schemas less tedious and less prone to manual error?

14. With a good number of Technical Advisory Board members present in Washington, we began developing a set of evaluation criteria for what we have come to refer to as “repository management tools”.

15. Be sufficiently robust as to support the creation and maintenance of PESC schemas based on components contained in the tool’s repository Have the ability to import existing schemas, both PESC schemas and schemas from other sources Be able to create schemas from repository-based components that are backward-compatible with existing PESC schema definitions

16. Be able to store schemas in separate namespaces to accommodate existing PESC schema definitions, which provide like-named elements and types that exist in separate namespaces Be able to create a new schema file and namespace from Repository-based components Provide the ability to move a component to a new namespace

17. Provide the ability to create new components from subcomponents whose definitions exist in different namespaces Be able to conduct an Impact Analysis of a change to a definition contained in the repository and its affect on other components and schemas Provide the ability to see parent/child associations and relationship history across components and schemas

18. Be able to support multiple versions of the same definition (concurrent versions as well as those in various development stages) for components and schemas Have the ability to publish/deploy definitions within the repository in multiple formats such as plain text and Comma Separated Values (CSV)

19. Provide a means to publish contents of the repository to a Component Registry such as Federal Student Aid’s XML Registry and Repository for Higher Education, the ebXML Registry and Repository, etc Have the ability to identify elements and components that are not used within another component or schema definition Provide a means to track changes made to components and other artifacts (such as a sample instance document) stored in the repository

20. Provide a means to store supporting information (sample instance documents, change history, documentation, etc) and tie it back to the corresponding component Provide the ability to generate a report that details the results of an Impact Analysis. This report could serve as evidence of due diligence by a PESC workgroup that is adding or changing an element, component, or schema Be able to generate instance documents based on a schema definition residing in the repository

21. Next came the search for tools that might provide at least some of the capabilities enumerated on the previous slides. There aren’t many. In fact, we have found one. But it is very promising.

22. We’re excited about this tool, but we are proceeding cautiously in order to make the best decision for PESC and the Community. Being a volunteer force also constrains the amount of time that we can devote to our evaluation as well.

23. We will deliver schemas that allow software tools to generate what they need to produce PESC XML – not the extra baggage that is created today. We want to get the word out that this issue is being addressed, and provide an update on our progress.

24. Questions?

25. Thank you for attending and participating in today’s session. Stay tuned for further updates!

26. The Technical Advisory Board is an EOEO. Suggestions, as well as new members, are always welcome! smargenau@glhec.org You may also contact Michael Sessa or Jennifer Kim, and they will get the information to us.