Please send all comments on/corrections to these minutes to Laura Green.

Working group co-chair Owen Ambur convened the meeting at 9:05 a.m. at the American Institute of Architects. Attendees introduced themselves.

Announcements

1. Mr. Ambur asked for attendees to review the March 14 meeting minutes and forward any comments or corrections to Laura Green (LMI).
2. Mr. Ambur announced that Tuesday, April 24, he will be participating in a symposium on Capitol Hill discussing LegalXML. He hopes to learn how XML will be used on Capitol Hill to mark up legislation and the U.S. Code.  [Editor's note:  Owen's meeting notes are available at http://xml.gov/documents/completed/coax_meeting_notes.htm.]
3. Mr. Ambur also announced that he and fellow co-chair Marion Royal met with Lisa Nelson of the GSA to discuss how best to strengthen the WG's relationship with state and local governments. They discussed possible ways to include state and local governments in the WG's work. If any WG members have any ideas as to how best to go about doing so, please contact one of the co-chairs or post on the WG listserv.
4. Finally, Mr. Ambur announced that Bill McVay of OMB inquired as to whether XML should be one of the technical standards recognized under the A-11 capital asset planning and budget justification process. Mr. Ambur recommended that XML should be recognized in the 300B Exhibits required by the process.  If and when the WG's XML registry has been established, as a prerequisite for receiving funding consideration, he suggested that OMB ought to ask agencies if they had registered their data elements and schemas in the registry.
5. Glenda Hayes (MITRE) announced that the Federal Database Colloquium will be holding its annual 2-3 day event this year in San Diego the last week before Labor Day. The Colloquium still has an active call for papers, and abstracts are due Monday, April 23. Dr. Hayes added that, with regards to soliciting state government participation in the WG, the IRS is developing XML schema for federal tax forms. Part of this work involves a tax information group for electronic requirements standardization, which is a group of state agencies. The WG could get in touch with this group to solicit state participation in its work.
6. Mr. Ambur announced that the agenda for next month's meeting will include updates of RosettaNet's and ebXML's work. Mark Crawford (LMI) has offered to conduct the ebXML update presentation. Mr. Ambur asked if anyone else wanted or ought to be included in the presentation.

Those members participating in the meeting via teleconference then joined the meeting and introduced themselves.

Presentation: "DLIS Repository Services"

Charlene Woodman of the Defense Logistics Information Service (DLIS) briefed the WG on the repository services offered by DLIS. This presentation will be available on the XML WG website.

The Defense Logistics Information Service, a subordinate command of the Defense Logistics Agency, has the mission to create, obtain, manage and integrate logistics data from a variety of sources for dissemination as user-friendly information to meet or exceed the needs of DOD, Federal and international logisticians. As part of fulfilling its mission, DLIS serves as a provider of both data and repository services.

For the last three years, DLIS has worked with the joint logistics community to provide data integrations and services. One of the projects DLIS and joint logistics community have worked on is the creation of a DLIS metadata repository that overlaps with DLIS's XML repository. The joint logistics community, not DLA or any other specific agency funds this initiative. DLIS wants to use this metadata repository to support data integration and sharing as well as eBusiness initiatives throughout the logistics community. DLIS wants to posture itself to handle not only transactions but also the data contained within them. The repository will also help manage data and let everyone know what the data standards are. Additionally, since the logistics community includes a wide variety of legacy systems, the repository should help with translation and mapping of data from one system to another. The DoD has recognized that it has done a poor job of data management over the past few years. The DLIS metadata repository should make data management easier.

Ms. Woodman then showed the WG a slide that gave a high level view of the repository architecture. The metadata repository is about data elements and data exchange requirements, as well as information exchange requirements. The same data is exchanged with many people. DLIS wants to document exchange requirements and sort that information in the repository. It does not matter where the data is going; the repository is simply a tool to enable someone to construct a data-sharing environment. DLIS is currently working on an XML repository that will support the business transactions going on within the logistics community. The goal of the XML repository is not to register data elements; there are other initiatives that are taking care of that task.

The metadata repository utilizes Product Data Markup Language (PDML). PDML itself utilizes XML. The DLIS metadata repository can support any kind of DTD or schema. One of DLIS's goals is to use whatever commercial standards are available so that, in theory, any user could query the repository.

The metadata and XML repositories could stand alone, but are designed to work together. The goals of the metadata repository are to implement an integrated data environment, manage business agreement, and manage configuration of the integrated environment and repository data. Both configuration and business agreement management are key parts of data sharing. DLIS's emphasis is on reference data models and mappings that can translate information, because the logistics community includes many legacy systems that are many years old, are used for many different things, and are set up in many different ways.

The DLIS metadata repository has been constructed to be ISO 11179 compliant.

DLIS's XML registry/repository initiative is a work in progress. It is currently web accessible and utilizes PDML. One of the capabilities of the XML registry/repository will be execution time mission critical processing. This capability reflects a difference in DLIS's needs from those of a commercial organization. The repository needs to be able to actively interact with the process. This repository will be ready for a demonstration by the end of this July, and will be ready for deployment at the start of the fiscal year.

If anyone has any further questions about DLIS's repository services, he or she should contact the organization at its Battle Creek headquarters.

Bruce Hoglund (DLA) asked what database the registry/repository is based upon.

Ms. Woodman replied that DLIS is using an Oracle database.

Mr. Crawford asked for an explanation of the difference between the repository DLIS is building and the one the Defense Information Systems Agency (DISA) is building.

Ms. Woodman replied that the biggest difference is that the DISA repository is declarative, while the DLIS one is active.

Mike Todd (OSD) pointed out that DLIS is supporting business processes, and that is a major difference.

Ms. Woodman added that DLIS is using PDML to automate business processes with XML.

Dr. Hayes stated that right now DISA's repository is strictly web based, but DISA exploring possibilities for application access to allow a flow of information.

Mr. Todd commented that this effort will lead to an integration of efforts in the future.

Dr. Hayes added that there is extensive integration and participation ongoing between DLIS and DISA.

Ms. Woodman said that both agencies are seeking to complement one another.

Mr. Crawford observed that DLIS was chartered to be the DoD's data manager. In his mind, it should have responsibility for identifying who uses what data as well as managing that data.

Dr. Hayes responded that DISA is providing a structure for data management. There has been a proposal to create a community of interest for namespaces, and DLIS has been nominated to manage that effort.

Mr. Crawford observed that since DLIS is the DoD's data maintenance agency, it is troubling to see any communities of interest namespaces being developed outside of DLIS.

Ms. Woodman responded that DLIS has a community support and is hoping to form more partnerships.

Presentation: "eXtensible Markup Language (XML) at DLIS"

Sherry Horton and Jeff Greger of DLIS then briefed the group on DLIS's work with XML. This presentation is available online in both HTML and PowerPoint formats.

The presenters played DLIS's CD-ROM "business card" as an introduction to the agency, its mission, and its services. This information can be found at the DLIS website. The presentation highlighted the fact that DLIS is a data broker and is always looking for new ways to provide data more quickly.

Ms. Horton then briefed the group on DLIS's XML accomplishments and development flow. So far, DLIS has established an XML working group whose members come from all impacted areas within the agency. The working group has completed a charter that provides buy-in from its commanders. DLIS has provided XML training both for managers and programmers. DLIS has also taken a survey of customer requirements for initial XML data exchange capabilities. Additionally, DLIS has prepared two task orders, one for program support and one from DSIO to help with the a modeling effort to map DTDs. Finally, the DLIS XML working group is seeking to partner with external XML working groups to learn from those groups' experiences and provide interoperability.

DLIS has also drafted the framework for an Operational Concept Description to determine how different XML is and how it will impact the organization. DLIS still needs a few months to model data for DTDs, as the Federal Logistics Information Service (FLIS) contains a great deal of data. The working group is also evaluating software tools and is working with vendors to get web-based demos of those software tools.

The next slide provided a view of the repository development flow. The dotted lines of the diagram denote areas that pertain to XML. These are areas DLIS has not explored before. DLIS is looking at standardizing names and data elements and definitions. It needs to work with DoD data management gurus to ensure that it is doing so properly. Staff members working on the XML repository area are also working closely with OASIS and DISA.

Mr. Greger then presented a view of the XML repository's capabilities. This diagram represents how DLIS views the data exchange capability it is attempting to build. DLIS has many users in the field, many different customers, and many different databases to interact with. One of DLIS's past problems has been getting direct data to a database in real time. Hopefully, XML will be the answer to this problem. Users will come in to a customer server. Customers will implement an XML to XML exchange between their servers and the DLIS server. This implementation requires a simple inquiry document that allows the interchange of a National Item Identification Number (NIIN). Customers can also chose to view the data in several different formats.

FLIS data is stored in DLIS's AS/400 database. The DLIS XML server determines if the customer query is a valid XML document. If it is not, the server will return a message that indicates where the errors are located in the document. If the document is valid, then the DLIS server will act upon the query and send formation back out to the customer site. DLIS has already modeled two of its different segments. While the modeling process is very difficult, once it is done, it is a simple matter to create query and response DTDs.

The DLIS XML working group was established in July of 2000. Currently, the group is completing the development and testing of Phase One DTDs. Phase Two of the effort will add additional query and output capabilities, and Phase Three will add even more capabilities. DLIS hopes to have a robust information providing capability online by August of 2001.

DLIS recognizes that it faces some challenges. It still needs to determine XML data element naming conventions, implement XML Capability, identify XML repository/registry requirements (both within DLIS and within the DoD), and evaluate software tools such as XML SPY and XML Canon.

DLIS is currently using the software tool Near and Far to develop its DTDs. Near and Far has been an easy tool to use, for it works on and displays the hierarchical structure of data elements and attributes within a DTD. So far, DLIS has developed three DTDs: an error DTD, a data DTD, and a query DTD. While the modeling effort that led to the development of these DTDs was very complex, Near and Far allowed the actual DTD development to run quickly and smoothly. And, while painful, the modeling effort will provide an excellent way for DLIS to document all of its data requirements, as many of these requirements are documented only in the heads of employees who will soon retire.

Dr. Hayes asked if DLIS was able to leverage a model for the names of its data, or if it was using column names.

Mr. Greger responded that DLIS is not using column names. Rather, it is using its organizational data dictionary.

Dr. Hayes asked if the names in the DLIS data dictionary were consistent with those in the Defense Data Dictionary System (DDDS).

Mr. Greger replied that the lower level DLIS data elements have been registered with the DDDS. Some DLIS data elements have not been. In the absence of specific guidance, DLIS has decided to be verbose with its names. It is considering reducing the size of the names by using underscores and "camel case." The choice to be verbose in naming elements and attributes is based on an assumption that there will be enough bandwidth available in the future to carry long names.

Dr. Hayes mentioned that the Treasury has been looking to use XML schema to represent codes, to use the schema to actually carry the description of codes and their values so that they will be programmatically accessible.

Mr. Greger stated that DLIS is moving from the use of DTDs to the use of XML schema.

Ward Breighton (NSF) asked for an explanation of camel case.

Mr. Greger informed the group that it is a naming convention in which the first letter of each word is capitalized and all of the following letters are not. There are no underscores used, and no capital letters are used at all in attribute names.

Dr. Hayes commented that, with respect to the verbosity of element names, DLIS could use XML algorithms to squeeze down ASCII messages. Verbose messages could thus be replaced with a single character.

Mr. Hoglund asked what DLIS is using for its XML server.

Mr. Greger replied that DLIS is using an NT server. Contractors are looking into different software tools to run the server, but DLIS has not selected one yet.

Mr. Hoglund asked if XML document validation was carried out by DLIS's XML web server or by the customer's own server.

Mr. Greger replied that DLIS's XML server validates all documents.

Dr. Hayes asked if DLIS has been investigating the use of SOAP.

Mr. Greger responded that DLIS has not yet taken a look at SOAP, as it is still in the process of learning about XML from its vendors. SOAP has not yet come up in their discussions.

Lex Poot (DTS) asked if DLIS is using Oracle.

Mr. Greger replied that DLIS is moving out of its AS/400 environment and into an Oracle one.

Mr. Poot pointed out that data can be saved in XML in an Oracle database.

Mr. Ambur remarked that Oracle will make a presentation to the WG at its June meeting.

The WG then broke for fifteen minutes.

Presentation: "Lessons Learned in DISA's XML Registry Initiative and Implications for XML.gov"

Dr. Glenda Hayes of MITRE briefed the WG on the Defense Information Systems Agency (DISA)'s work with XML and implications of this work for the WG. This presentation is available at the WG website in both HTML and PowerPoint formats.

In the course of her presentation, Dr. Hayes addressed DISA's market-driven strategy for XML implementation, its vision of an electronic marketplace for XML, the Defense Information Infrastructure-Common Operating Environment (DII-COE), and XML coordination and guidance.

Dr. Hayes began by discussing DISA's data management challenges. Organizations have to expect to be confronted with a heterogeneity of data. They cannot expect to have one standard with the DoD. An agency could be completely compliant with a standard with respect to certain groups, but often times, the more compliant one is with standards, the more transformations one has to be able to make between data formats. This is not a good situation, but DISA does not believe it will change.

XML exacerbates this problem because it is very easy to make XML; all a person needs is an editor. Designers have lowered the bar in terms of creating XML artifacts and schemas that everyone can create them. W3C added an extra twist to this by making nametags case sensitive—this makes it very easy to create non-interoperable XML.

So the question posed to DISA is that given that it must take care of data in a common operating environment (COE), what approach should it take in terms of trying to manage this data. The DoD has tried to use the top down approach, but was less than successful in doing so. The top down approach led to the creation of more bureaucracy, middle level managers, and data checkers, but no more interoperability.

DISA has thus decided to adopt a market-drive strategy. In order to work in a market-based environment, mechanisms must exist for identifying the players and providing a visibility of the goods available. Additionally, there has to be a way for the marketplace to play out so that developers can advertise their wares and reuse those wares that work. It is only through reuse that DISA believes it will be able to achieve commonality and help program managers reduce cost, risk, and schedule time.

The major players in the marketplace will be the developers, the community data managers, and the defense acquisition policy managers.

One of the important features of the market approach is the provision of low barriers to entry. DISA wants to provide visibility to everyone. If a programmer has developed a data component and it is in use by a system, DISA has to provide visibility so that that data component will be managed. Another feature of the market approach is the focus on components as a unit of exchange. An element or an attribute can be viewed as a resource. Additionally, the market approach focuses on communities of interest (COIs) as trading arenas. This allows groups to define their own semantics so that they are not in competition with the semantics of other data forms. Finally, program engineers will be the primary traders in the market. DISA does not want to create another group of bureaucrats that will exist in competition but have no authority.

DISA views its electronic market as a "data emporium." This emporium provides reference data sets, database segments, and other items. The latest member of the data emporium is the XML registry.

The rules of the marketplace outline the means and requirements for registration. Again, there is a need to make the boundaries to entry low so it is easy for anyone to gain visibility.

The organization of the marketplace must recognize the need for configuration control. DISA needs to be able to manage different versions and provide components to provide interoperability between versions.

Next, Dr. Hayes briefed the WG on DISA's electronic marketplace for XML. DISA's XML registry is a part of this marketplace, and it went online in May 1999. This registry is designed to run on a person-web page model of interaction. Currently, there is no application-web page capability. The registry handles the registration and management of components, an approach that the DoD is considering adopting.

There are two rules within the COE for the registry. The first is that if a program uses XML in a public manner, then the elements and schema used must be registered with the registry. This meets Level 5 of the DII-COE compliance guideline. The second deals with how namespaces are created. DISA is working on replacing the use of the word "namespace" with "community of interest."

The collection of communities of interest represents both vertical and horizontal business markets. This is because there are some communities that cross multiple business areas (e.g., the messaging community). There is also an Enterprise community of interest, which serves as an area of convergence. These communities of interest provide a bottom-up approach wherein the communities develop agreements within themselves. When other communities see opportunities for semantics to span other areas, then those semantics are expanded up to the enterprise level. There is also a namespace known as "The Big Dump," in which reside components that have yet to be assigned to a namespace. This provides visibility to all components.

DISA hopes to infiltrate industry groups. In many cases, the government is doing better than industry, so government should not always be looking to industry for answers.

Mr. Breighton asked if DISA has looked at storing data for research grants.

Dr. Hayes replied that there is not yet a common model for grants data, so they have been unable to develop an XML schema.

Alesia Jones-Harewood (DISA) added that research grants are not yet in a position to be a namespace. She then asked what process is for creating a new namespace.

Dr. Hayes responded that some communities outside of the DoD have expressed interest in becoming namespaces. The interested group approaches DISA and, if there is no preexisting suitable namespace, DISA works with the group to prepare it to brief the architectural oversight group.

Dr. Hayes then briefed the WG on DISA's XML registry. The goal of the registry to make it easy for developers to find and reuse components. Additionally, DISA wants to make it easy for groups to submit their components to the registry. Granted, groups do have to submit specific documentation of their components, but this documentation is necessary if applications are to be able to easily access the components. DISA hopes that the registry will decrease the amount of variability inherent in XML systems.

The registry currently supports certain information resource types. These types are listed in the presentation. DISA is gravitating towards the use of XML schemas.

Dr. Hayes outlined the process by which groups can submit new components to the registry. DISA believes the reuse will only occur if it is benefits the program managers in terms of risk, schedule, and cost.

Mr. Todd asked what DISA is doing to identify the incentives for reuse.

Ms. Jones-Harewood responded that DISA is not trying to force the community to use the registry. The marketplace mindset dictates that DISA merely make components available for free use.

Dr. Hayes added that in the absence of policy that is practical and effective, if something does not meet a program manager's budget, it will be ignored.

Ms. Jones-Harewood remarked that DISA has to make a marketplace part of the funding string that program managers must adhere to. If the need to look for opportunities to reuse components is written into acquisition policy, then DISA will teach the program managers how to look for it.

Mr. Niemann asked if the process involves any kind of parsing validation to check the compliance of XML documents submitted.

Dr. Hayes replied that it does not. If a document is submitted complies with the DTD, it should be provided with immediate visibility. There is a check for potentially embarrassing material. Once the document has cleared that check, it is given a grade of "developmental" and must be registered to a namespace.

Earl Warrington (GSA) asked if "The Big Dump" includes only developmental stuff.

Dr. Hayes replied that it includes developmental stuff and components that have become obsolete and that are deprecated in favor of something new.

Mr. Warrington remarked that "The Big Dump" must then also be used for version control.

Dr. Hayes agreed, but added that version control can also occur through the namespaces.

Ms. Jones-Harewood asked who manages "The Big Dump."

Dr. Hayes replied that DISA does.

Dr. Hayes then showed the WG an example of the component submission package. DISA has been criticized for making the documentation process too detailed, but this documentation must be done if a component is to be used between systems.

DISA is seeking to leverage existing metadata assets; the DoD has made a huge investment in metadata. The objective is to get it into the registry.

Dr. Hayes provided the WG with three case studies that illustrated how DISA is leveraging these preexisting metadata assets. The first involved USMTF. The second involved data models. The third involved XML schema definition.

Dr. Hayes then briefed the WG on DISA's XML coordination and guidance. Ms. Jones-Harewood runs the namespace manager's forum. For a diagram of DISA's XML management structure, please see this slide.

The DII-COE has created several compliance levels for XML. Level five denotes meeting the minimum level of compliance. Level seven indicates that a group has agreement within its community of interest. Level eight indicates that the component has made it up to the enterprise level and must be used.

Mike Johnson (GSA) asked how DISA is coordinating cross-namespace commonalties.

Dr. Hayes replied that this coordination occurs through the namespace manager's forum.

Ms. Jones-Harewood added that all of the namespace managers vote on whether a component ought to be used enterprise-wide. It is not required that groups maintain a certain compliance level, but maintaining that level will help them.

Mel Stockwell (IONA) commented that the reuse of metadata is a step in the right direction. He asked if DISA has looked into doing web service to get the community to actively use the registry. He suggested that DISA utilize UDDI and SOAP.

Dr. Hayes commented that DISA still needs to consider UDDI and SOAP, and it that it actually has some advice for UDDI. UDDI is based on a completely replicated registry, while DISA's registry provides a much finer level of granularity of services. DISA is considering a much more federated design to distribute the burden of hosting. This requires all sorts of shades of exploration.

Sam Cottrell (Data Networks) asked what criteria DISA uses to determine if an artifact is still in use.

Dr. Hayes replied that DISA does not have that capability right now, but it will be included in the next evolution of the registry.

Ms. Jones-Harewood added that DISA needs for systems to come in and update it periodically.

Dr. Hayes commented that DISA is trying to get way out in front and to make sure that it can answer the mail for the policy developers and data managers.

Mr. Ambur remarked that he is interested in learning lessons from DISA's work and figuring out how the CIO Council could best leverage DISA's knowledge. In addition, the WG needs to consider how best to advise the CIO Council.

Ms. Jones-Harewood pointed out that the reason DISA wanted to brief the WG is to form a relationship where the two groups can leverage each other. DISA wants to be a link off of the WG registry. DISA wants to be able to get an agreement or relationship where the it and the WG can sit on each other's group meetings to make sure DISA's registry can carry federal components. The DISA registry is not intended to be solely for the DoD's use.

Mr. Ambur noted that the WG does not have a registry yet.

Ms. Jones-Harewood remarked that DISA can educate the WG on creating a registry and provide some software for it to explore.

Mr. Ambur commented that the WG wants to remove obstacles and encourage people to do the right thing, rather than try to force them to act through policy that may not be enforceable anyway. He suggested that DISA contact Lisa Carnahan, who is the steward of the registries page on the xml.gov site.

Next Meeting: May 16, at GSA.  The room number is listed in the agenda at http://xml.gov/agenda/20010516.htm

XML Working Group Attendance List