Embed Size (px)
Citation preview
igniteXML and Component Management for PESC
Presented by the Technical Advisory Board
Hyatt Regency WashingtonOn
Capitol Hill
Wednesday, April 8, 2009
2
What Is The Problem We’re Trying to Solve?
Our decision to maintain our definitions at the Schema level has resulted in a cumbersome process for people and a memory-intensive schema architecture for information processing.
PESC’s interests would be best served by maintaining our definitions at the component level.
3
• 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.
A Little History………………………..
4
• 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……………………
5
Middle InitialLast
Name
Last NameFirst Name
Middle Initial
First Name
Core
Sector 1 Sector 2
6
Middle InitialLast
Name
Last NameFirst Name
Middle Initial
First Name
Core
Sector 1 Sector 2
7
What can digitalML’s igniteXML do for PESC?
Eliminate use of the CoreMain and Sector schemas.
Provide a repository for individual schema components, both simple and complex
An interface that allows a schema to be created or changed using components stored in igniteXML’s repository
The ability to perform an impact analysis and create a corresponding report before any change is applied
8
The ability to identify components in a schema or other structure that are not being used
Web access to some of igniteXML’s schema design tools in order that schemas may be created and modified by a workgroup as their design is refined
Multiple levels of access control
9
Current Scheme Creation Process
1) A workgroup identifies the data items their new standard requires in order to meet the needs of their constituents. This activity utilizes the most recent versions of PESC Core and Sector schemas.
2) The workgroup determines whether each data element they need exists in the Department of Education’s Registry and Repository for the Education Community, and categorizes each data element into one of three categories:
• The data element exists in the Registry and Repository and its definition can be used as-is
• The data element exists in the Registry and Repository but its definition can only be used if it is modified.
• The data element does not exist in the Registry and Repository
10
Current Scheme Modification Process
1) A workgroup identifies the data items their new standard requires in order to meet the needs of their constituents. This activity utilizes the versions of PESC Core and Sector schemas in use by the workgroup’s current standard.
2) The workgroup determines whether new data elements they need, as well as modified versions of existing data elements they need, exist in the Department of Education’s Registry and Repository for the Education Community, and categorizes each data element into one of three categories:
• The data element exists in the Registry and Repository and its definition can be used as-is
• The data element exists in the Registry and Repository but its definition can only be used if it is modified.
• The data element does not exist in the Registry and Repository
11
3) The information for each category (“a” through “c” above) is recorded and maintained in a spreadsheet that has a tab for each of the three categories (above). Each tab of the spreadsheet records the following information:
Sector Library Name (if applicable)Tag NameBusiness TermDefinitionRelated Terms (if applicable)Data Type (string, integer, etc)CardinalityMin LengthMax LengthPattern (if applicable)Enumeration List values (if applicable)Component Type (simple, complex, etc)Parent elements (if applicable)Child elements (if applicable)
In addition, for items falling into categories “a” and “b” (above), “Classification” is included. This item specifies the class of information the item falls under – information about a person, information about aid received, etc. This document will be referred to as the “component definitions document” going forward in this text.
12
4) The workgroup completes the upper portion of the Schema Issue Review form (Industry Requesting Review, Description of Issue/Problem, and Requested Change/Resolution).
7) The component definitions document contents are approved by the CCB when no questions or issues remain. The CCB completes the center section of the Schema Issue Review form, marking the Changes Request Approved box, or the Changes Request Denied box and providing an explanation for the rejection. The remaining steps (below) occur if the CCB approves the output of the workgroup.
5) The component definitions document and Schema Issue Review form are provided to the Change Control Board (CCB).
6) All line items in the component definitions document are reviewed by the CCB. Issues and questions from the CCB are referred back to the workgroup and addressed.
13
9) The schema editor reviews the information on the spreadsheet and provides feedback to the workgroup, for example, in cases where an element that does not exist in the Registry and Repository is actually defined in the most recent Core schema. The schema editor reviews the spreadsheet and determines the location for new elements being added to the PESC universe, such as Core or Sector. The location for elements existing in the Registry and Repository but needing a modification to their constraining attributes is also determined (most likely a Sector schema).
8) The component definitions document is passed to a volunteer from the Technical Advisory Board (TAB) for creation of new schemas and updating existing schemas (currently this volunteer is from a non-member organization and their availability is potentially subject to change). This text will refer to this person as the schema editor.
14
10)The schema editor downloads current versions of the Core and/or Sector schemas as necessary. If needed, the schema editor creates copies of the Core and/or Sector schemas which the new standard will impact; these copies will become the new version. Using a tool such as XML Spy or a text editor, the schema editor keys new and/or modifies existing components within the Core and Sector schemas. If appropriate, a new Sector schema will be created as well. The Minor or Major version numbers of the Core and Sector schemas are incremented due to the additional and/or modified elements.
12)The revised and/or new schemas are provided to the Change Control Board for review. The CCB also reviews documentation for the new standard.
11)Once the new and modified elements have been defined, the schema editor creates the instance document schema for the new standard. These will most likely reside in the applicable sector schema. The schema editor saves the new versions on his local machine and on their employer’s network, if available.
15
15)New schemas are provided to the PESC Executive Director for posting on the PESC website. The PESC Director creates a press release regarding the publication of the schemas and the timeframe for a 30-day Review for Public Comment period.
13)The CCB reviews the schemas and documentation. The schema(s) are reviewed visually and may be loaded into XML Spy or other tool to assess validity. There is no current PESC standard recommending which tool(s) to use. Schema contents and documentation are approved when the CCB has completely addressed any questions or issues.
14)The schema editor completes the 'Schema Changes' section of the Schema Issue Review form with a description of what was modified for the schemas and in some cases, creates a point-by-point documentation of the changes made.
16
17)The PESC Executive Director publishes the Response to Public Comments developed by the Change Control Board.
16)At the end of the 30 day period any comments received are reviewed with the workgroup. A response to each comment is created by the Change Control Board with input from the workgroup as necessary. In the unlikely event that public comments result in a change, the process returns to step 10 and the work of the schema editor in which components are added or modified.
17
19)After the schemas are published to the PESC Web site they are evaluated in conjunction with the Department of Education’s XML Registry and Repository for the Education Community. Any changes are incorporated manually into the Registry and Repository.
18)The PESC Executive Director announces the availability of the new standard. The revised and/or new schemas are moved to the areas of the PESC website where other approved standards reside. New or revised documentation is also posted.
18
19
20
Current Scheme Modification Process
1) A workgroup identifies the data items their new standard requires in order to meet the needs of their constituents. This activity utilizes the versions of PESC Core and Sector schemas in use by the workgroup’s current standard.
2) The workgroup determines whether new data elements they need, as well as modified versions of existing data elements they need, exist in the Department of Education’s Registry and Repository for the Education Community, and categorizes each data element into one of three categories:
• The data element exists in the Registry and Repository and its definition can be used as-is
• The data element exists in the Registry and Repository but its definition can only be used if it is modified.
• The data element does not exist in the Registry and Repository
21
3) If there are more new and/or changed elements than can be comfortably described with free-form text in a one-page document, the information for each category (“a” through “c” above) is recorded and maintained in a spreadsheet that has a tab for each of the three categories (above). Each tab of the spreadsheet records the following information:
Sector Library Name (if applicable)Tag NameBusiness TermDefinitionRelated Terms (if applicable)Data Type (string, integer, etc)CardinalityMin LengthMax LengthPattern (if applicable)Enumeration List values (if applicable)Component Type (simple, complex, etc)Parent elements (if applicable)Child elements (if applicable)
In addition, for items falling into categories “a” and “b” (above), “Classification” is included. This item specifies the class of information the item falls under – information about a person, information about aid received, etc. This document will be referred to as the “component definitions document” going forward in this text.
22
4) The workgroup completes the upper portion of the Schema Issue Review form (Industry Requesting Review, Description of Issue/Problem, and Requested Change/Resolution).
7) The component definitions document contents are approved by the CCB when no questions or issues remain. The CCB completes the center section of the Schema Issue Review form, marking the Changes Request Approved box, or the Changes Request Denied box and providing an explanation for the rejection. The remaining steps (below) occur if the CCB approves the output of the workgroup.
5) The component definitions document and Schema Issue Review form are provided to the Change Control Board (CCB).
6) All line items in the component definitions document are reviewed by the CCB. Issues and questions from the CCB are referred back to the workgroup and addressed.
23
9) The schema editor reviews the information in the component definitions document and provides feedback to the workgroup, for example, in cases where an element that does not exist in the Registry and Repository is actually defined in the most recent Core schema. The schema editor reviews the component definitions document and determines the location for new elements being added to the PESC universe, such as Core or Sector. The location for elements existing in the Registry and Repository but needing a modification to their constraining attributes is also determined (most likely a Sector schema).
8) The component definitions document is passed to a volunteer from the Technical Advisory Board (TAB) and is used for updating existing schemas (currently this volunteer is from a non-member organization and their availability is potentially subject to change). This text will refer to this person as the schema editor.
24
10)When necessary, the schema editor downloads the version of the Core and/or Sector schemas currently used by the existing standard. If needed, the schema editor creates copies of those Core and/or Sector schemas which will become the new version(s). Using a tool such as XML Spy or a text editor, the schema editor keys new and/or modifies existing components within the Core and Sector schemas. The Minor or Major version numbers of the Core and Sector schemas are incremented due to the additional and/or modified elements.
12)The revised and/or new schemas are provided to the Change Control Board for review. The CCB also reviews modified documentation but only where such modifications were deemed necessary by the workgroup.
11)Once the new and modified elements have been defined, the schema editor creates the instance document schema for the new standard. These will most likely reside in the applicable sector schema. The schema editor saves the new versions on his local machine and on their employer’s network, if available.
25
15)Changes made to existing schemas, and documentation, will be included with the next quarterly release.
13)The CCB reviews the schemas (and documentation, if necessary). The schemas are reviewed visually and may be loaded into XML Spy or other tool to assess validity. There is no current PESC standard recommending which tool(s) to use). Schema contents and documentation are approved when the CCB has completely addressed any questions or issues.
14)The schema editor completes the 'Schema Changes' section of the Schema Issue Review form with a description of what was modified for the schemas as part of the request. A cover document for the quarterly release is also created with point-by-point documentation of the changes made as part of that release and associated change requests form related to each modification.
26
27
28
New Schema Development/Modification Process
1) The workgroup identifies the data items their new standard requires in order to meet the needs of their constituents. This activity may include browsing the PESC Core Components and Sector Libraries (Library Cabinets) hosted via the igniteXML Consumer Server (ICS). The focus is on identifying and possibly downloading existing core components that can be leveraged for the new schema.
If the workgroup is changing an existing standard, the workgroup identifies the new data elements and/or changes to existing data elements they need.
The workgroup must also identify a “Core Component Organizer” who will assist them with modifications to core components and the creation of schemas using the schema repository tool. This person can be a member of the workgroup who has a license for the tool or it may be a member of the Technical Advisory Board.
29
2) The workgroup requests the Technical Advisory Board to create a workspace within a specified cabinet[1] in order to model the XML document(s) being proposed. This will include the root document definition as well as any proposed additions or changes to core components to meet the work group’s requirements.
A workspace is a work area for modeling and developing proposed changes. The term comes from the igniteXML tool for such a work area.
The workspace will be created in the appropriate Sector Library Cabinet to which the workgroup is assigned.
The workspace’s initial contents reflect the current state (baseline) of any core components and schemas that reside in the Sector Library Cabinet to which the workgroup is assigned. Additional core components and schemas can be imported into the Cabinet as needed, either at the outset, or at any time during the creation of the workgroup’s proposed additions or changes.
The workgroup activities have no impact on production schemas as long as the changes are made in the workspace.
The workgroup consults with the TAB to determine what portions of the PESC core component set should be present in the Cabinet in which the workspace resides.
[1] The current organizational paradigm calls for the creation of 1 Cabinet per Sector Library. A determination will need to be made whether the new standard is to be developed in an existing Sector Library or a new one, requiring the creation of a new Cabinet in igniteXML.
30
4) The workgroup models and develops their proposed document(s) as well as any additions or changes to existing core components. This is done directly in the workspace by a license user using the full version of the modeling tool, allowing for the addition of new core components as well as the modification of existing ones.
While this can be done in stages, the submission to the Change Control Board and Technical Advisory Board must include all new and modified components as well as supplemental documentation and instance documents.
Careful attention must be paid to the ramifications of proposed additions and changes to existing schemas in other areas. The tool can assist with this.
3) The Technical Advisory Board creates the workspace on behalf of the workgroup for the modeling and development activities of the workgroup.
31
5) When all proposed additions and modifications have been modeled in the workspace, the workgroup checks in the changes along with all additional requirements. This results in a notification email to the Change Control Board (CCB) and Technical Advisory Board (TAB), alerting them to start the review process.
32
6) The proposed modifications are reviewed by the CCB and TAB in the checked-in workspace. Issues and questions from the CCB are referred back to the workgroup and addressed.
The TAB consults with the workgroup to resolve technical issues in modifying the workspace contents according to CCB/TAB concerns.
Documentation for new standards is also reviewed by the CCB. In the case of a change being made to an existing standard, the CCB reviews modified documentation only where a modification was deemed necessary by the workgroup.
The new and modified components in the workspace are approved by the CCB and TAB when no questions or issues remain.
This step is completed when the CCB has no further issues with the workgroup’s design.
Completion of this step constitutes the CCB’s approval of the new design.
33
8) The TAB generates a schema from the design as accepted by the CCB.
7) The TAB creates a Build from the approved workspace (and has the option of including changes from other workspaces) which incorporates all relevant component additions and changes.
The workgroup is notified via email (automated by igniteXML or sent manually by the TAB) that the changes have been applied to the Cabinet(s).
34
9) New schemas and, in many cases, the corresponding documentation, are provided to the PESC Executive Director for posting on the PESC website. The PESC Director creates a press release regarding the publication of the schemas and the timeframe for a 30-day Review for Public Comment period.
At the end of the 30 day period any comments received are reviewed with the workgroup. A response to each comment is created by the Change Control Board with input from the workgroup as necessary.
In the unlikely event that changes are necessary after the public review period, the workgroup will be responsible for incorporating the changes. The process, in effect, returns to Step 4 above.
The PESC Executive Director publishes the Response to Public Comments developed by the Change Control Board.
The PESC Executive Director announces the availability of the new standard. The revised and/or new schemas are moved to the areas of the PESC website where other approved standards reside. New or revised documentation is also posted.
After the schemas are published to the PESC Web site they are evaluated in conjunction with the Department of Education’s XML Registry and Repository for the Education Community. Any changes are incorporated manually into the Registry and Repository.
10) Changes made to existing schemas are released quarterly.
35
36
37
38
39
• Questions?
40
• Thank you for attending and participating in today’s session.
• Stay tuned for further updates!
41
• The Technical Advisory Board is always looking for ways to improve and enhance PESC. Suggestions, as well as new members, are always welcome!
• You may also contact Michael Sessa or Jennifer Kim, and they will get the information to us.
