GSA
Headquarters
18th
& F Streets, N.W, Room 5141B
Washington
DC 20405
Please send all
comments or corrections to these minutes to Glenn Little at glittle@lmi.org.
Mr. Owen Ambur: We might as well get started. We generally start with introductions. I’m Owen Ambur, co-chair of this Working Group along with Marion.
[Introductions all around, including several phone-in participants.]
Mr. Ambur: There may be some people still trying to get into the building. Ken [Sall] had offered to escort people who are a few minutes late, but he hasn’t arrived. Hopefully, people won’t be stranded. Bruce [Troutman] will check in a little bit.
The first presentation is by a group accompanying David Connelly of Open Applications Group. David, what does the I stand for in OAGI?
Mr.
David Connelly
XML
Working Group OAGI Briefing
Mr. Connelly: Well, it’s a long story. We were OAG when we incorporated in ’95, and the Official Airline Guide (OAG) sent us a “Cease and Desist” order because we were a “.org.” The Official Airline Guide was owned by Reed Elisiver, and they have more money than we, so we settled. You can call us OAG. I just can’t, so we’re OAGI.
We have a quick set of three presentations today. I’ll give a short brief on Open Applications Group—on who we are and what we’re doing, then Sandra Swearingen will brief us on the Air Force’s work on OAGI/GCSS, then Nenad Ivezic will cover the work they’re doing in our Testbed with NIST [National Institute of Standards and Technology]. We’ve divided our time into even slices, so each of us has 17 minutes, with 9 minutes at the end for questions. We had to reboot the projector here, so we should be ready in just a minute…
Mr. Ambur: If Abraham Coy from the Air Force doesn’t make it due to the snow, we’ll have more time than that.
Ms. Sandra Swearingen: Someone from PureEdge was…
Mr. Will Gorman: I’m Will Gorman from PureEdge. Steve Jacek is stuck at home, so I’m here to speak on some things going on in the market and why we’re here today.
Ms. Theresa Yee: Are the presentations available online?
Mr. Ambur: The only one made available to me before the snow was Sandra’s.
Mr. Connelly: The others have been sent in since the snow, so they may be able to go up after the meeting.
Mr. Ambur: Yes, I’ll put them up.
[Editor’s note: All of the presentations are now available at http://xml.gov/presentations.htm#20030219]
Mr. Marion Royal: Are the Air Force folks here out of Scott [Air Force Base, St. Louis]?
[Yes.]
Mr. Connelly: Nenad is out of NIST.
Slide 2 [Agenda]: I’ll start by telling you a little about who the Open Applications Group is…[projector came up] here’s the agenda slide. First, we’ll talk about OAGI and the Air Force, then Nenad will talk about the Testbed.
Slide 3 [Open Applications Group: Who We Are]: The Open Applications Group is a 503(c) corporation—not for profit—formed in ‘95 for promoting interoperability between business software applications, and to create or endorse one or more standards for interoperability. Our strategy has been building standards—primarily business standards—then adopting other technologies like SOAP or ebXML.
Slide 4 [OAGI Activities]: Our primary activities are:
1) Technical standards work,
2) Helping build interoperability between partners, and
3) Outreach.
Slide 5 [Short History]: We were incorporated in 1995—one of the first post-EDI organizations. We were looking at a new model for interoperability, the model being loosely-coupled asynchronous meta-data based architecture. Our current use of metadata is the fourth generation for OAGI—as the first generation the technical teams invented before XML was around—then XML DTDs [Document Type Definitions], then XML XDR (XML Data Reduced), and then XSD (XML Schema).
We’ve been prototyping with XML since ’97, and so the OAGI constituency has a lot of experience in building schemas as well as user components and implementations. Does everyone know what ebXML is?
[Several participants indicated unfamiliarity.]
Mr. Connelly: It was a project that was run by a joint effort of the United Nations and OASIS. They put together a worldwide project to kick-start XML based on e-business standards around the world. The primary deliverable was 4-5 technologies being implemented around the world. They didn’t deliver the business language or payload. They did an envelope language to carry the payload and they built architecture and process technologies also. OAGI has been involved since December, 1999. The Open Application Group announced adoption of the work and contributed our body of work before it was concluded. We also started a project last year to harmonize the OAGIS core components with Core Components at UN/CEFACT.
Mr. Royal: How is that?
Mr. Connelly: I’ll be covering it in just a minute in the presentation.
Slide 6 [Technical Activity Focus]: Our technical activities focus mainly on these areas— Business Scenarios, Business Object Documents, Core Components, and XML Schemas & Examples.
Slide 7 [OAGIS is Process Definitions and Payloads]: Here’s a purchasing scenario--sending a purchase order and receiving an acknowledgement. This is a UML diagram, and we include these in the standard for customers to use as reusable models for their business process designs. Then there are messages, which are made up of a Noun and a Verb. That’s what the specification primarily is—the messages and their XML expressions, and the process definitions.
Slide 8 [Business Object Document]: The Business Object Document, or BOD, is the basis for the scenario. We’ve built up the language of nouns and verbs we can use over the years. Why would we do that? The amount of data to cancel a purchase order is less than that required to process a purchase order. It gives people the option to send “fat” or “skinny” BODs over the wire. Most people use the fat BOD concept because it makes programming easier. You send the entire package and strip off what you want at the other end. It also has an implied process model because OAGIS doesn’t require that framework as part of the model.
Mr. Royal: Does “Core Components” consist of nouns and verbs?
Slide 9 [OAGIS PO Noun]: Each of these boxes is a Core Component, which could be made up of smaller messages. Over 50% of the messages we build today are made up of pre-existing Core Components.
Mr. Royal: Your Core Components equate to ebXML BIE [Business Information Entity]?
Mr. Connelly: Nouns might. I would say the Core Component or the noun would be related to a BIE.
Mr. Ambur: For the record please explain what the acronym BIE stands for.
Mr. Connelly: Business Information Entity. The verb constrains the noun, meaning you can deploy a common object library, with the same characteristics across nouns. In the DTD world, you couldn’t constrain nouns. You had to have duplicates for each DTD, so the “Process PO [Purchase Order]” noun in a DTD looked different from a noun in “Cancel PO.”
Slide 10 [Verbs
Constrain the Nouns]:
[Skipped—addressed in the preceding discussion.]
Slide 11 [OAGIS Core Components]: The Core Components are building blocks. We’ve been doing this for many years—since ‘95, so it’s well assembled. We have the current version (8.1) of OAGIS out for comment.
Mr. Royal: It’s incorporated?
Mr. Connelly: Into 8.1.
Mr. Royal: What do you call a Core Component broken down to its most primitive structure?
Mr. Connelly: I don’t think I understand your question.
Mr. Royal: UN/CEFACT Core Components are broken down to their most atomic state.
Mr. Connelly: We have that, plus a little more. What we’re trying to do with the Core Component effort is reconcile those two approaches—also with the UBL approach.
Mr. Royal: I’m just trying to understand the terminology.
Mr. Connelly: We have those fine components. We also go several degrees up from there. It’s really a way to pull UN/CEFACT, OAGI, and UBL efforts into a dialogue.
Mr. Royal: I’ve been working on UBL stuff, so I’m listening very carefully. Maybe we should do a follow-up instead of taking everyone’s time right now.
Mr. Connelly: Sure, Maybe a telecon with our chief architect. We can talk later to try to set that up.
Slide 12 [Core Components Plan: Our plan is to use this as the basis for UN/CEFACT contributions over time. We’ve committed to contribute candidate Core Components.
Slide 13 [Current OAGIS Release]: This is what [version] 8.0 looked like. In version 8.1 we go to 450 messages, so it’s pretty large and mature. We’ve got 8+ years of efforts under our belts.
Slide 14 [Current Scope of OAGIS Content]: We worked on not just e-commerce, but manufacturing, logistics, and CRM. We support not just Business-to-Business, but Application-to-Application. So the enterprise can support any language in an application, whether it’s inside or outside the firewall.
Slide 15 [OAGIS is the Horizontal Solution]: We call it a canonical model for Business Language. So this supports many functions. We’re also working with many vertical organizations to add their specific needs to the vertical backbone, so XML Schema with substitution groups allows us to support the vertical. It’s similar to extensions. It’s working right now.
Slide 16 [Interoperability Activities]: We do have interoperability activities. Nenad will cover that.
Slide 17 [Out-Reach Activities]: We spend a lot of time on outreach. We go to UN/CEFACT, AIAG, OASIS, and many other entities that you see listed here. Many companies have implemented OAGIS—HP, Agilent, IBM—deploying it as a canonical model.
Slide 18 [UN/CEFACT Endorsement]: This is a UN/CEFACT endorsement. This is just one of many that we have, just to show that we’re not a “fly by night” company.
Slide 19 [OAGIS Joins MoU Group]: We’ve joined the four international de jure standards bodies in a memorandum of understanding. The four standards bodies are ISO, ITU, IEC, and UN/ECE. The highest you can become in the standards world is a user group of one of these four. [OASIS is a member, and so is EAN [European Access Network—http://www.wmin.ac.uk/ean/. SWIFT [Society for Worldwide Interbank Financial Telecommunication— http://www.swift.com/] is lobbying to get in.
Slides 20-26 [Endorsements]: I’ll just run through these. As you can see, we have many endorsements from quite a few well known, high-profile organizations. This includes trucking, motorcycle, manufacturing—a large number of industries.
Slide 27 [TranXML Acquired]: We recently acquired TranXML, and we’re looking to migrate it into the overall OAGI.
Slide 28
[Projects Summary]: Here are
some of the types of projects we’re involved in. Everything from testing, to
Core Components, to working with the verticals.
Slide 29 [OAGIS Live in 39 Known Countries]: The latest count is that OAGIS is running live in 39 countries around the world. That includes some pretty exotic countries. I think there’s one in Fiji.
Slide 30 [OAGIS Used in Over 35 Known Industries]: It’s used in over 35 known industries. This is still growing, but these are the best numbers we have right now. Some are in defense.
Slide 31 [OAGI Example XML Implementations]: Here are some example implementations. The Quebec government is the only organization we know of that has translated our tags.
Unidentified participant: They’re probably required to by law.
Mr. Ambur: So the other countries are using English?
Mr. Connelly: They are. The Asians as well, for the tags. The data is another story. You lose the point if you don’t do that.
Slide 32 [Summary of OAGIS]: In summary, we’ve been around awhile, and we have worldwide adoption .
Now let me turn it over to Sandra [Swearingen] to brief us on what the Air Force is doing.
Mr. Royal: Do you have quarterly get-togethers?
Mr. Connelly: Yes. The last one was last week, and the next one is in April, sponsored by NIST.
End Presentation
Ms.
Sandra Swearingen
Air
Force Communications Agency
US
Air Force/Open Applications Group Activities
I’m Sandra Swearingen from the Air Force Communications Agency. I work out of Scott Air Force Base in the Enterprise Information Division, and I’ll be talking about the Air Force’s Open Applications Group activities.
Slide 2 [Overview]: We’re the Air Force representative to OAGI. Lockheed Martin is the chief GCSS [Global Combat Support Systems] integrator for the Air Force. We have David Vanatta from Lockheed Martin on the line with us. Lockheed Martin is using OAGI standards in the GCSS-AF. We have a strategy of using OAGI standards with the Air Force for Enterprise Information Management applications. We have a pilot going on for Web Services technology to assist us in interoperability.
Slide 3 [AF OAGI Representation]: As I mentioned, we’re the Air Force representative to OAGI. Doc Savage, who is here with us, generally goes to the meetings. We were asked to join by Lockheed Martin Systems Integrator. We saw the need for standards participation, so we officially joined in November, 2001. In 2002, we had an Air Force Day in Dayton, Ohio, where we brought others from the Air Force in to see applicable areas of OAGI standards.
Slide 4 [TGCSS-AF]: GCSS is designed to provide secure, accurate, timely, ubiquitous combat support information to the operator. It supports all Air Force functional areas—22 areas, which we call pillars.
Slide 5 [GCSS-AF Architecture]: We see the GCSS architecture as divided into an Application Framework and an Integration Framework. Within the application Framework, we have Applications and Reusable Business Components, and within the Integration Framework we have Technical Services, Integration Services, and Infrastructure. OAGI BODs fit into the Reusable Business Component layer.
Slide 6 [GCSS-AF Interfaces]: The Air Force approach to interfaces is to use OAGI specification-based BODs. With our acquisition reform, we want to align with industry. We don’t want a “military solution.” We want one that works with industry. We’re also using Web Services and XML standards where we’re integrating applications.
Slide 7 [EIM Integration]: Our goal is to establish a knowledge reservoir of functional interoperability between EIM applications. The user will log on through the GCSS portal, then gain access to all the EIM systems. We record information about issues and initiatives in the Enterprise Corporate Analysis - Time Saver, or ECATS, knowledge exchange; we even have an initiative about this [CIO Council XML Working Group] group. We’ve been tracking this group and the Navy [DON XML] Work Group. Our goal is an integrated suite of products that empowers users to electronically create, coordinate, collaborate, and obtain approval of any official action in a seamless intuitive environment. By using XML and business object documents developed in accordance with the OAGI Interface Specification, we can plug and play them and make them work together.
Mr. Ambur: Before you leave this slide, a couple questions: First, do you have contact with the CIO Council’s Knowledge Management Working Group?
Ms. Swearingen: We’re working a lot with a lot of groups. If you provide me the information afterward, we can put them into ECATS if they’re not there. We’ve been following collaborative tools. There are many being used right now in the Air Force. Some are even “White Boarding.” ECATS is a 24/7 non-real-time system over the Web—not a white board.
Mr. Ambur: I mentioned to you in an email that this slide prompted me to wonder how the components identified in your EIM relate to the Federal Enterprise Architecture, particularly the Service Component Reference Model. I wouldn’t expect you to have worked out all the relationships yet, but it will be important over time to see how your components map to the FEA.
Ms. Swearingen: We believe our EIM strategy is consistent with the FEA and the Service Component Reference Model. I’m in the Enterprise Information Management area, but there’s a Document and Records Management branch in our division. I gave them your question and will ask them to follow up with your records management question.
Mr. Robert (Doc) Savage: If I read that Web page you passed us as intended, then the element that will align will be the Enterprise Transport layer within the GCSS Enterprise Framework. Right now, the message is massed for the UNIX side, but it’ll expand to Web Services. We expect any application that can communicate with a future Web Services back end. We’re going to try to make that pathway as open as possible.
Mr. Ambur: Your CIO, John Gilligan, co-chair’s the CIO Council’s Architecture and Infrastructure Committee, to which this working group reports, so he’s in a pivotal position to make a difference.
Mr. Savage: The GCSS program is one of his programs. We have an architectural group headed by Colonel David Gruber, called the Architecture Sub-Council (which manages the Air Force's Infostructure Technical Reference Model). How that lines up, we’ll have to see.
Mr. Ambur: The sooner we can identify reusable components, the better off we’ll be. Document and records management are of particular interest to me. Lisa Weber is here with us from NARA. Also, the Association for Information and Image Management (AIIM) has a group working to identify the functions of document versus records management systems that should be integrated to provide for full life-cycle management of information.
Ms. Swearingen: We’re certainly in a receptive mode. If anyone has solutions to share, we’re always looking for new ideas.
Mr. Savage: The objective is a capability that’s not standalone or a login as part of a suite.
Ms. Carol Yang: What about security? Is there any involved?
Ms. Swearingen: David?
Mr. Savage: Applications themselves can invoke whatever leverage they need. There is built-in security between enterprise transport nodes—that’s HTTPS. If your application needs to hook into Web Services security, we’d expect your interface to have a pass-through to those interfaces. Web Services security is still evolving.
Mr. Connelly: Yes—it’s the highest priority in the Web Services community. Today OAGI supports digital signature. That’s all we can do today. The “best practices” are SSL [Secure Socket Layer] or VPN [Virtual Private Network] or private lines. No one’s advanced the state of the art. Web Services is looking at a combination of those and PKI [Public Key Infrastructure]. There’s no single best practice, but many know it’s very important.
Ms. Yang: And the PKI…?
Mr. Connelly: Yes, that’s part of the mix.
Mr. Savage: In the diagram you see the single logon. Behind that is PKI with Active Directory or LDAP tree. We have it reduced initially, behind the curtain. It will be an ambitious project for the Air Force and DoD to get a single directory tree structure for permissions.
Mr. Royal: Are you looking at the Federal Bridge authority to link to “.gov” people?
Mr. Savage: I’ll defer to the Air Force people in the Air Force technical model community.
Mr. Royal: If not, I recommend looking at the FBCA [Federal Bridge Certificate Authority] for sharing PKIs, sharing trusts to allow organizations to accept authentications, etc. I don’t know whether your part of the Air Force is looking into this. The question I have is, I see the single sign in, which I assume is for all applications, but what other interoperability is there?
Ms. Swearingen: This is a concept of the future. We intend to have ECATS and E-STARS share whatever they need to share, so it’s a matter of defining what needs to be shared, then using OAGI BODs and XML tags vis-à-vis what’s in the XML registry to move the data.
Mr. Royal: These are individual groups?
Mr. Savage: Yes…
Mr. Royal: How do you get them to agree on what to exchange?
Mr. Savage: By using the OAGIS methodology to see what we need to exchange back and forth and then building the BODs. For example, in KM, that’s a running history of a particular issue, but it may be suspended in E-STARS with management toward a particular date. It’s possible in either system to open a path to the other and initiate a timeline from one to another.
Mr. Royal: Do you start by asking each to model its process?
Mr. Savage: We’re doing just that—decomposing the data elements of each, and doing a functional review to see exactly which are needed by the others. We’ll implement as BOD exchanges.
Mr. Royal: What level of cooperation are you getting?
Ms. Swearingen: Lockheed Martin is the implementer of ECATS and E-STARS, so we’re very lucky in having a high level of cooperation.
Mr. Royal: So you’re starting with several, to expand to others or put others out of business?
Mr. Savage: If we could find a COTS [Commercial Off-The-Shelf] product that does a better job than either of those, we’ll drop them and plug in the new one.
Mr. Royal: This is what we’re doing with EGov—looking at how to trust someone, looking at processes. That’s the difficult part, getting started.
Ms. Swearingen: Whatever does it better and cheaper is what people will support.
Mr. Ambur: Sandra, you talked about registry services. Is DoD XML Registry adding value in the process?
Ms. Swearingen: We have to get more involved with the XML registry community. We’re following your email discussions about the Registry.
Mr. Ambur: We have a registry/repository team that meets under the auspices of the XML Working Group. Roy Morgan of NIST heads it. It is scheduled to meet again this afternoon.
[Editor’s note: Due to the snow, the Registry/Repository Team did not meet as scheduled. Instead, Roy provided a brief update at the end of this meeting.]
Ms. Swearingen: The DoD Registry will mature, and your goal isn’t one federal registry, but to make sure they can talk as they need to, so that’s great.
Mr. Ambur: I have a hard time getting my mind around all of the myriad workflows and how we can add value to them, but it is not hard to understand how we can add value in the specification of the data elements and schemas supporting the business processes. A schema or set of schemas is implicit in each of these applications. What is needed is to make them explicit so that we can see where common and perhaps inconsistent and/or needlessly rendundant data requirements exist.
Ms. Swearingen: So we have these common applications that talk to each other. We hope to plug-and-play Enterprise Management applications the way you plug an appliance in at home.
Slide 8 [EIM Integration (continued)]: We want a seamless functional exchange of information. We do it using XML-based BODs for data exchange, facilitated by XML and Web Services technology.
Slide 9 [Web Services]: This is a graphic about Web Services. I like this diagram. Web Services standards are in the shape of a plug and outlet. People say, “Hmm, your plug’s not grounded, but the outlet is.” The hole is security. That needs to be addressed with Web Services also.
Mr. Royal: At least it’s built in to the infrastructure.
Mr. Savage: To the extent that your application needs it, it’ll be available.
Ms. Swearingen: Web Services need a business language to travel over the wire, and OAGIS is this business language.
Slide 10 [Take Aways]: So we want to create an interoperable environment with a total approach to automation, not locked into proprietary applications. We use GCSS OAGIS/XML to enhance the exchange.
Slide 11 [Summary]: The Air Force fully supports adoption of XML technology. I’m personally involved with this work, so I’m very familiar with this. I support the adoption. We have Air Force technical architectures getting updated as they emerge, and they’re including XML standards. We’re very active in using OAGI specifications in our systems, and we’ve been closely following the work of others—groups such as the Navy and the Federal CIO Council XML Working Group.
Mr. Ambur: How is XQuery coming along?
Ms. Swearingen: I was in it since ’99. When they re-chartered, our organization disbanded its formal standards office, so I follow it by email right now. The chair of the committee is involved in ISO SQL. They have a data portion and a document portion.
Mr. Ambur: I’m looking forward to seeing how Topic Maps and XML Query can be used to identify related and potentially inconsistent and/or redundant data elements and schemas in the XML Registry.
Ms. Swearingen: There’s going to be an International Web Services and XML conference in Toronto in March. Now I’d like to introduce Nenad Ivezic. He’ll talk about the NIST Testbed.
End Presentation
NIST Manufacturing Systems Integration
Division
OAG/NIST B2B Interoperability Testbed
Mr. Ivezic: I’m coming from the Manufacturing Systems Integration Division of the manufacturing engineering labs at NIST. The objective today is to give you an overview of the Testbed supported by OAGI and NIST. It’s an open Testbed, available to those who would like to make use of its resources.
Slide 2 [Outline]: I’ll try to touch on the important points. I’ll go over the participants, the vision, the architecture (the general architecture of the Testbed and its functionality), and provide an example of a current project we’re doing to work in collaboration with an automobile industry group, and then I’ll talk about international cooperation.
Slide 3 [Participants]: From the beginning, we’ve been adamant about involving all stakeholders—including vendors, industry consortia, users, and government standards organizations. We have about 50+ members looking at the Testbed, directly contributing in technical development or user scenarios.
Slide 4 [Testbed Roadmap (Vision]: The Testbed is 11/2 yrs old. In the beginning, we asked users and vendors what made sense as a productive use of the Testbed. We identified a wide spectrum of opportunities. One end is Web-based infrastructure to demonstrate and pilot interoperability any time, any place via web browser. The other end is to develop a Testbed for customer-driven application-to-application (A2A) interoperability testing, demonstrating A2A over business-to-business (B2B) infrastructures such as ebXML, Rosetta Net, etc., and piloting for B2B infrastructures—so we can help in many areas. We agreed to demonstrate at an early stage using vendor-driven scenarios, then using user-driven scenarios. Then our goal is to eventually develop a Testbed that can support on-demand testing and demonstration, and have user- and vendor-defined metrics, all in a non-competitive environment.
Slide 5 [An Interoperability Pilot Architecture]: To give you an example, this is showing an interoperable architecture developed to support an automotive retailers’ organization and their project. They’re interested in demonstrating their XML standards for their use case, and developing a series of processes and XML documents to support their transactions between dealers and original equipment manufacturers. It’s shown how the Testbed can interact with two middleware engines. It provides for messages being passed, logging and processing them to check conformance of business processes with specifications agreed upon by vendors and specified by the Star X consortium.
Slide 6 [A Business Scenario: Automotive Retailers - Parts Order]: This is one scenario we looked at. It consists of five messages being passed:
Mr. Royal: This is the Star consortium?
Mr. Ivezic: Yes. The lesson learned was, it took between two and three weeks for this business process to go through the issues of misinterpretation of the standard (in this case, BPSS XML), to agree on a common shared understanding of this business process and follow these agreed-upon definitions to demonstrate the interoperability in this pilot. This agrees with what we’ve been hearing in industry—5-7 weeks of administrator time per transaction—quite a bit of time.
Slide 7 [Testbed Architecture]: This shows the Testbed architecture being supported at this point; actually, the interoperability stack. We provide support at the message, business process, and content level. So far, we’ve focused a lot on ebXML standards for business processes, messaging, and content checking. Specifically on messaging, it requires so many HTTP messages being passed. The SOAP message is an add-on. As long as it’s HTTP-based and the BOD is XML, we can adapt to any ebXML or SOAP.
Mr. Royal: Do you have anyone looking at an alternative?
Mr. Ivezic: At NIST we had Patrick Gannon from OASIS listen and talk to David. He was interested, and he brought up the possibility of it being used by OASIS. This is an open Testbed, so UBL is certainly welcome. NIST is interested in brining in UBL and OAGI and Rosetta Net to talk about sharing the definitions. As a side note, an upcoming workshop in May at NIST is going to be focused on that very issue--“How to reuse and share standards for e-commerce and B2B,” so it would be great to have you over.
Slide 8 [Testbed Functionality]: This is a summary of the Testbed. It’s a distributed architecture. At this point, given that we can support multiple participants, we can first allow tests of application outputs asynchronously, so we don’t need another participant to synch; we can use the Testbed as a virtual partner and test the initial behavior of the application without having a required participant.
Mr. Royal: I’m trying to understand the BOD approach, and knowing about the DPSS from XML, it seems that with nouns and verbs and the choreography of a specification, it would only have to have a CPA with business partners, and use BODs. Why is it necessary to have a PBSS at that stage?
Mr. Ivezic: We’re trying to separate the layers. OAGI BODs specify the verb in a way of defining a transaction, but the business process is a choreography of multiple transactions, like supply chain management, inventory management, or whatever, so it’s initially shown in “Process Parts Order, and can be followed by multiple transactions.
Mr. Royal: So the Star scenario gives the timeouts, and the BODs don’t?
Mr. Connelly: The verb gives context to the BOD, so it’s more intelligent than the process, but it doesn’t define a machine-readable process.
Mr. Ivezic: You can use the Testbed Web interface to fire the message back and test the behavior. Next, you can test with respect to conformance with the other test.
Slide 9 [Accordare Reflector]: It has a number of tools to test the messages being interchanged. We have a way to test what’s being specified about content; we can test what’s specified as constraints, and see if messages conform.
Slide 10 [Business Process Monitoring]: This shows you snapshots of the components that support these. You have a model that follows the logic of the choreography. It sees whether messages follow the agreement. The color coding indicates the status of messages at different points in time.
Slide 11 [Content Checking: Sample Report]: We have the capability to check content. We’re interested in defining semantic constraints of the content. For instance, we want to enforce on delivery date and shipping date, etc. It was developed in cooperation with Lockheed Martin and the Air Force to support the Enterprise Portal environment.
Slide 12 [Content Constraint Specification Wizard]: That was developed on the basis of Schematron, which is a language that allows assertions on top of XML and XPath. We’re developing the capability to let the user develop constraints in a faster way.
Slide 13 [Prototype of a Virtual Trading Partner]: We’re interested in developing a prototype virtual trading partner that would allow a test of the model to test all business language, so a company can check its applications as much as possible before production
Slide 14 [A Current Project: Inventory Visibility and Interoperability]: The current project is from the automobile manufacturing industry. The landscape of suppliers in different tiers is very complex. Currently, to support visibility between tiers, each company is using different tools, with different and proprietary interfaces. It amounts to a many-to-many situation between the lower and upper tiers. One has to support multiple tools for up- and downstreams. It’s very costly for lower tiers to support several tools. We’re looking at agreeing upon a language for these tools, to allow use of any tool to support upstream or downstream.
Slide 15 [Ensuring Interoperability: Common Data Model and Semantics]: Next steps—we’re looking at fields that need to be supported in the data model. You see here that a number of these support specifications for data exchange, but some don’t. But we’re working out how it’ll be done. We’ll have to have sessions on the shared semantics and data, and on the basis of our experience with the Testbed. We’re hoping to develop a test to support this as well as possible.
Mr. Connelly: We’re combining development of XML schemas concurrent with interaction with the Testbed.
Mr. Ivezic: It’s more proactive in developing messages, rather than at the end of the lifecycle.
Slide 16 [Collaborators and Phases]: Some of the collaborators are OESA, AIAG, and Odette. We have buy-in from tier 1 and 2 companies. We’ll help in Phases 2 and 3, but in particular, Phase 4. International collaboration is very important—OAGI implementation, possibly to send to the Asian area.
Slide 17 [International Collaboration Strategy]: We’ve initiated one and possibly another. The first is with Koreas—the KorBIT Testbed. The second is an ebXML pilot, looking at collaboration with Europe.
Slide 18 [Korean B2B Interoperability Testbed Consortium]: In Korea, it’s a consortium of users and developers, to test conformance and interoperability of their software that will support multi-user communities, including the auto and steel industry.
Slide 19 [KorBIT-NIST Testbed Collaboration Strategy]: We hope we can develop collaboration with the U.S. and Europe so we can develop a memorandum of understanding between them and Korea, so that at the end of the day, the testing technology will be at least similar enough that if one passes on one side, it’ll be recognized as having passed on the other side. This is going on now. In the coming months, we’ll identify how we collaborate in the future.
Slide 20 [A Potential European Collaboration]: This is a collaborative effort with CEN-ISSS and OASIS to develop a shared infrastructure with further testing effort, identifying possible low-hanging fruit.
Slide 21 [Next Steps: Services Oriented Architecture]: We’ve focused so far on ebXML to support B2B interoperability. What you see here is an architecture from a recent General Motors [GM] pilot. It showcased ebXML infrastructure support of a B2B interface, also with a Web Services interface supporting back end integration. Our hope is to develop a Testbed to support both B2B XML and A2A issues. This is strategic. It should take place over the next year. Both GM and Ford indicate they want to develop it further.
Slide 22 [Summary]: In summary, I’ve shown you an overview of interoperability piloting in the Testbed currently supported by OAGI and NIST. It’s an open environment. We welcome others to collaborate with. We believe that as a technology lab of the Department of Commerce, we bring important resources, and are an important technology player to support this work through excellence in measurement and standards.
Mr. Ambur: Your focus is B2B, but I’m curious to know whether any of the eGov project managers have thought about the need for the capability you provide. Under the eGov initiative, four portfolios of projects have been identified: government-to-citizen, government-to-government, government-to-business, and internal efficiency and effectiveness. Have any of the portfolio managers or project managers approached you about taking advantage of your capabilities?
Mr. Savage: The Air Force intends to use the Testbed to certify their systems before implementing.
Mr. Connelly: How would we go about looking in to that?
Mr. Ambur: Marion is a key link from this Working Group to the FEA Solutions Architects Working Group [SAWG].
Mr. Connelly: Maybe do a session on that Working Group’s agenda?
Mr. Royal: I’d consider getting a tie-in to the Industry Advisory Council. They’ve been working with the SAWG. It provides an entry point to non-governmental organizations.
Mr. Ivezic: I’d be interested to bring others from NIST and have them present their work. There’s a NIST-wide testbed, an information technology lab, and an electricity and electronics lab. This is just one part of NIST’s testbed activities. Taking it to the next level of government work is of interest.
Mr. Bruce Troutman: For me, the issue was the seven weeks to get the message agreed upon. If you expand that to all of the messages we have to document, some benefit would come from your experience in that process alone—in how successful and unsuccessful it’s been, what are good ways to approach it—because parties don’t always have the same vision at the beginning, but they need the same vision at the end. Are there any ideas about taking that process and saying, “We found these improvements?”
Mr. Ivezic: Capturing those lessons learned is high on our priority list. We have a bunch of notes, and we’re ready to share with those who are ready to see them. To make a leap from anecdotal evidence to something more technical is going to take effort, but we have interest from NIST and others to do more than just episodal efforts in this area.
Mr. Troutman: You need to share that—we need the human part more than the technical part.
Mr. Connelly: We’ve heard anywhere from two to three days for ones with common infrastructure, to where everyone’s equal in strength and position and it takes longer to hammer it out.
Mr. Troutman: We need anecdotal stories of success and failure. It helps us figure out how to pull these together—talking millions of messages.
Mr. Ambur: The CIO Council also has the Best Practices Committee, to which the KM Working Group reports. When I think of collaboration, I think of the schema required to support it. That is, what are the XML elements that define collaboration? The Air Force has its KM initiative and I know the Navy has placed a lot of emphasis on KM too, but what are the common elements? We should capture the logic of collaboration – what might be called metaknowledge – and represent it in an XML schema that can be deployed and reused in KM applications across any organization.
Mr. Royal: I’m struck with the comment of developing a schema through the prototype. I think that’s a little dangerous, because often it’s quick fixes. Even OAGIS looking at modeling approaches. I’m a little scared of that…
Mr. Ivezic: I probably misspoke. It’s referring to the inventory visibility project and a way to develop schema and a semantic model. The intent is to develop tools to translate Core Components, to take them from a library and using them to define a data model of shared semantics—more tool-driven, not prototype-driven.
Mr. Royal: David—if one’s looking for OAGIS information for people with little time, do you have a primer you can recommend?
Mr. Connelly: Let me send you something. We have articles on the website. We’ve done a host of them in the XML Journal. I’ll send them to you.
[Editor’s note: A White Paper describing the OAGIS specification as a result of this exchange is now located at http://xml.gov/documents/completed/oagi/oagis.htm.]
Mr. Ambur: Very good. If there are no other questions, we’ll take a 5-10 minute break and then hear about the Air Force’s eForms automation project.
Break
Mr. Ambur: OK, let’s get started again. We’ve had a few people join us since we introduced ourselves at the start of the meeting. If they’d like to introduce themselves, we’ll give them the opportunity now.
[Introductions]
Mr. Ambur: We’re going to swap time slots here. There’s still a chance that Abraham [Coy] may make it in, so we’ll go with Will [Gorman] and PureEdge first.
Mr.
Will Gorman
PureEdge
USAF
Forms Automation Project
I’m Will Gorman, Field Systems Engineer for Pure Edge. I work with Steve Jacek, who can’t get out, so I’m here on his behalf.
Slide 2 [Pure Edge Overview]: We’re an XML forms vendor. When you talk about secure solutions, XML is the core of out technology. We’re privately held, founded in 1993, headquartered in British Columbia, and we’re an active participant in standards bodies. Our work is all based upon open standards. We have hundreds of implementations, and millions of users worldwide. We’re represented in the U.S. and Canada, with offices on both coasts.
Slide 3 [Committed to Standards]: We’re completely committed to standards. In our opinion, XML has to be open. We wrote XFDL. It’s currently in version 5.0, currently at the W3C for review and you can find it at http://docs.pureedge.com/. As far as XForms, is concerned, John Boyer is our Chief Architect. He wrote the specification for the computational engine and also edited the DSIG standard.
Mr. Ambur: Are you going to talk more about XFDL?
Mr. Gorman: I can talk about it here or at the end, whatever your preference is.
Mr. Ambur: I became aware of PureEdge when the company was called UWI.com. I became aware it through their proposed Extensible Forms Description Language standard. Contrary to what most technicians and vendors are pushing, I know from experience that presentation cannot be separated from data for legal reasons. As I understood it, the aim of XFDL is to bring presentation back together with content in order to provide legally sufficient records.
Slide 4 [Underlying Technology - XML]: UWI was our company name in ’97. We realized we’re not a “.com,” so we changed the name. At W3C, UWI is us. We originally created UFDL—a description langrage to connect data and have one object. We decided in ‘97 that XML was the way to go. We wrote XFDL to have:
Where we continue to see that benefit today is that XML is widely accepted. There’s a wealth of XML tools. It’s suited for long-term retention of records.
Slide 5 [Leadership]: We provide leadership. We were founded in ’93. Our first product was delivered in the fall of ’97. We began work with Microsoft in ‘98, and released XFDL in August of that year. We had the first XML e-form in the fall of ‘98, and in February of ’98 we were named a top 10 e-commerce company by “Commerce World.” We changed our name in 2000, and these are some of the awards that have followed. [The slide listed several industry awards.]
Slide 6 [Good Records]: This goes to the data presentation in one element. A good record has content, context, structure, and is bound in a single file. In the paper world, forms are the metaphor for the business process. When you fill out a form, it’s for collection, presentation, storage and retrieval of a business process. It begins the flow. If I fill out a form for a drivers’ license, they want to know who I am and where I live. Then they transfer that to the actual license, then in the future, they might retrieve it. If you open something with a .XFD extension, it’ll have everything. It has an enforceable signature. We use several types—Digital, Electronic, Click Wrap, Digitized, and Pin. These are freed into a controlled lifecycle. There are other vendors in the XML space. They can understand what we do in the process that feeds into their workflow. As a product line, we are a front-end business; we feed into their applications.
Mr. Ambur: Citizen centricity is supposed to be an overriding principle in the eGov Strategy, but when applications are being designed, the last thing developers consider is the user interface. In the case of highly structured data collection systems, the user interface is a form. We don’t need to take time to debate this today, but I believe we have all the business models we need in the forms we are using to support our ongoing business processes. In my view, the fastest and best way to specify our data architecture is to inventory the data elements on our existing forms. Then we can use the registry to facilitate collaboration among communities of interest to redude needless inconsistencies and redundancies. In short, I believe we should use a bottom-up approach to put citizen centricity into practice rather just using it as a rhetorical term.
Mr. Gorman: Another federal agency has some problems. They recognize that their systems don’t talk to each other, and they can’t capture the data. They fill out numerous forms, which reside in a back end, and don’t add value. We provide two pieces—a simple way to capture data, and by being XML you can search what’s there. It’s adding value.
Slide 7 [Adobe PDF]: Steve [Jacek] mentioned that you had other vendors who present here. I’ll just briefly mention where they are in the technology and provide some contrast. I’m not here to bash them—just to highlight the differences. Everyone has Adobe on their machines at home or the office. It’s great because it’s a precision presentation in static publishing of forms. It looks great, just like a thing you’d pick up at the office. It’s terrific, but it’s a proprietary format, so it’s not a lot of use once it’s done that one piece of work. No one can write into it or pull data out of it. It has limited functionality. If we want to manipulate it, it’s complex and expensive, and there’s great difficulty extracting data out of it. How many times have you wanted to cut and paste something from a PDF? As the file is worked on, it gets bigger and bigger. You have little control of the user experience.
Slide 8 [Adobe SVG]: Adobe has seen the value of XML. For that reason they’ve come up with Scalable Vector Graphics (SVG). It uses XML to represent graphics. It’s valuable where graphics need manipulation dynamically. It has limited functionality for capturing and processing text, which is what most people do. SVG is primarily an XML-based presentation, so it has the look and feel, but it’s not a transaction. It’s an adjunct to PDF, not a part of it. So Adobe has an XML piece, but not a solution.
Slide 9 [Microsoft XDocs]: Microsoft has XDocs. This is what Microsoft says: they won’t be XForms compliant; they don’t participate in the Working Group; and they don’t plan on compliance. Their model separates data and presentation. There’s no mention of integrity, digital signatures, or other security measures. When they announced their initiative, Adobe stock dropped 6% that day. It’s interesting to note that they say that XDocs will continue to be an integral part of the formal and informal business process.
They’re linked to the Office desktop. That’s great, but if it’s proprietary, it’s a closed environment, and if it’s linked to Office, does it meet your requirements to capture data and put it into your workflow?
Mr. Royal: The separation of presentation and data allows you to take it into the process in different formats. XDocs is doing it; the only restriction is the schema. Adobe does have significant XML capabilities when you buy their product.
Mr. Gorman: Well, Adobe is under the covers. It’s a separate product.
Mr. Royal: I don’t mind what’s under the covers as long as it’s what you can use.
Mr. Gorman: Microsoft says about itself that’s it’s a function of Office.
Ms. Yang: Office 11?
Mr. Gorman: Yes.
Mr. Ambur: Have they announced a decision to incorporate it into Office?
Mr. Gorman: Yes. Office 11. They announced it last week.
Mr. Ambur: I’m looking forward to Matthew McKennirey’s presentation next month concerning the legal sufficiency of electronic records.
Mr. Gorman: You have enterprise and department level niches. We see XDocs at the department level, so they’re creating a form and need to capture data in a form at the department level. Work with the Air Force goes through the enterprise, and that’s where interoperability comes into play and that’s what the technology should support.. Our file size is small compared to our competitors.
I’ve just talked about two very large vendors; they’re proprietary and not committed to open standards, and very expensive.
Mr. Ambur: The philosophy of the FEA is relatively small, reusable components. I’m not sure how that concept relates to the large office software suites. It will be interesting to see how that plays out.
Mr. Gorman: We’re at the front end. We see it as cooperation between technical, vendor, and enterprise partners to solve a problem. There’s usually a workflow piece where someone spent millions of dollars on the back end, but there’s no way to collect. You’re paying many to key in data that’s been done before. You have no way to do it, and you need a way to pull it out later.
Mr. Matthew McKennirey: When you save an XFD, can you open it in another program that understands XML?
Mr. Gorman: It’s kind of in a text editor. You can see all the tags and information, but not the pictures, provided the document design allows you to. When we talk about human readable, if 10 years down the road you need to read it, you can do so. It depends on what you use to read it. It recognizes that a text editor can see and understand how it’s made, what’s in the fields, and how it’s created.
Mr. McKennirey: I tried and couldn’t do that. I was wondering if it was the application. I opened the XFD document and just got a representation. I didn’t see the XML.
Mr. Gorman: XML is a grammar. It has rules about well-formedness. It’s a broad framework. We use XFDL to further define elements and components. We use ICS viewer to process the logic built into the XML. You say, “If I use Internet Explorer [IE], shouldn’t that see it?” We say no, because IE doesn’t have the process of the viewer.
Mr. Royal: When I open an XML document with XML Spy, I don’t expect the presentation, just the raw tree structure. Can I open the XFD with XML Spy?
Mr. Gorman: I’m not familiar with XML Spy. You’d have to try it.
Mr. Bruce Lyman: With the designer you can encrypt or not, or compress. Maybe that was part of it.
Mr. Gorman: We use a compression slightly off of the standard. I’d be happy to make it available.
Mr. Ambur: My first question about XFDL concerned its verbosity. The answer was that it lends itself well to compression, which was logical because XML itself compresses well due to its inherent structure.
Mr. Lyman: You can get a 10-page form down to about 15 Kilobytes.
Mr. Gorman: This is an example of the XFDL. All these are definable and readily available, based upon the standard. Compression was probably the problem.
Mr. Ambur: I’m pleased to hear that answer.
Mr. McKennirey: I’m pleased also, because I know XML and I couldn’t see it.
Mr. Royal Is XFDL an XML schema?
Mr. Gorman: Currently, no. We’re looking at what to do with the next release. Initially the company said we had choices. DTD was available, but they said, “Let’s not base our development cycles on that. Let’s go with what works. Let’s stick with XFDL and drive to what works.”
Mr. Royal: So the XFDL specification has to be in the reader product?
Mr. Gorman: Yes—it has to parse the XFDL product.
Mr. Royal: Are there future plans to express the specification as a schema?
Mr. Gorman: We see tighter integration with XForms, which uses schema.
Mr. Royal: Is XFDL a standard?
Mr. Gorman: Yes—W3C.
Mr. Ambur: Other vendords like Microsoft will say it’s not a standard, but that is only because they won’t participate in making it one. I don’t like that. XFDL is an attempt to meet real business requirements and vendors should come to the table to address them.
Mr. Royal: It’s a W3C standard, and whether Microsoft complies is between them and their customers.
Mr. Ambur: That’s what I’m saying. We have to be educated consumers. We can’t just accept the answers that vendors of proprietary products may want to sell us. We must meet the underlying business requirments, including the need for legally sufficient records.
Mr. Royal: I’m not impressed with product, where XML is embedded in the product.
[Mr. Gorman and Mr. Ambur disagree with Mr. Royal.]
Mr. Gorman: We say, “Here it is. If you find something you can’t use, pick up the phone and let us know.” The Air Force is saving $15,000 a month with this and $9,000,000 annually.
Mr. Ambur: Here’s an example. A number of years ago I saw two articles on the very same page of Government Computer News. One was about how agencies were failing to comply with the CFO Act and GPRA because they were failing to keep good records. The other was an article on Windows 98. What were the major enhancements to Windows 98? More entertainment features! I used those articles in a presentation I made that year to suggest that what we need is a Business Document and Data Manager client software application. I called the BuDDMan browser, whereby a user can fill out any form and file it anywhere in the world along with the necessary metadata to manage it as a record. We don’t need what Microsoft is selling us, at least not if we want to conduct business as we should. They’re not selling us business tools. They’re selling us entertainment.
[Editor’s note: The presentation reference by Mr. Ambur is available at http://users.erols.com/ambur/ASIS/KMvalue.html. The slide on which the two articles are documented is at http://users.erols.com/ambur/ASIS/KMvalue.html#missing and the BuDDMan “browser” is refenced is at http://users.erols.com/ambur/ASIS/KMvalue.html#slide30.]
Mr. Royal: I don’t want to get into the Microsoft argument. I don’t know how many corporations are on with XFDL. If it’s just PureEdge, then I don’t like it. If there are many, then OK, but I don’t like the specification embedded in the product.
Mr. Gorman: I disagree. I’m from the security world. At my former company we worked with PKI, security products. Those are embedded in products you see every day. When you use IE or whatever, there are PKCS7, or 11, or whatever.
Mr. Ambur: The issue is whether techies are willing to acknowledge the business requirement to tie presentation to content to ensure legal sufficiency.
Mr. Royal: I come from the PKI world too, and that’s not a good example. Those are embedded because product developers had to buy the licenses from the companies.
Mr. Gorman: XFDL is open and freely available on W3C’s site.
Unknown Participant: They also have a free reader.
Mr. Gorman: For some customers, some pay and some don’t. The Air Force’s is not free. Yes, it can be free to individuals, and also freely downloadable for a 30-day trial.
Slide 10 [PureEdge XFDL ICS Products]: So XFDL is an open standard, published at http://docs.pureedge.com/. In the second quarter of this year, we intend to incorporate the XForms data model. This will be more fully brought out by developers as we go along. Then I want to hit on the fact that it’s document centric. We see the metaphor for business as process-involved. We see it as the whole thing—fully offline capable, and a single file that can be digitally signed. For the Air Force—if you’re in the form, and you have a laptop—before you go somewhere you might have to requisition supplies, etc.. You must be able to do that off line. We provide the ability to take the form, work on it, and digitally sign it off line. You wind up with an XFD that’s digitally signed, compressed or not. It can’t be altered. Then there are tools about how to do it with the designer.
It has strong support for signatures. For the legal concept of “document,” how many times have you said, “Let me look at a particular document.” What makes it valid is there’s some structure, some content, and people recognize it as a certain document. That’s what we show. So if you have an XFD on your desktop and someone has a question, you can say, “Let me print it out,” and you can do it. If it’s an application you filed that needs to be brought back, it can either show you in the viewer or print it and show it to you. We’ve joined presentation and data. It’s important for the legal aspect. People say, “What’s the difference.” If you’re “on the stand” and someone shows you a row with no context, what’s that mean? If the attorney showed you it and you said, “Yes, yes, yes,” what’s it mean?
Mr. Royal: If it had the metadata on it, it would have the same legal ramification.
Mr. Ambur: Even that is not sufficient, because information that has been separated from its presentation can easily be distorted.
Mr. Royal: Say the problem is something back on page 52 that I didn’t notice when I signed. Then presentation means something, but otherwise it doesn’t.
Ms. Carolyn Watkins-Taylor: It means a lot if you’re in the Air Force and you’ve been rated and your report doesn’t look like the others. Then presentation is very important.
Mr. Royal: If I’m looking at sharing data, presentation is meaningless. I’m using the forms to put data into multiple systems…
Mr. Gorman: We can do both. For example, a large company in New York City spent millions on PeopleSoft. They said, “We have forms that need to tie in”—they said, “If I’m a user, why not key in the forms.” We said, “We’ll give you the electronic form. You fill it out, and it populates the back end of PeopleSoft. If you have any reason to go back, you can bring it back out, and the workflow still has the data it needs. You’re right that you need the data apart from presentation, but data and context also is important.
Mr. Royal: But then the data specification has to be backward-compatible with all previous versions. That’s another reason to have the data outside that application.
Mr. Savage: Then 10-20 years in the future, if you need to recover it...
Mr. Gorman: Absolutely. I’m sure the [National] Archives have something about that. How many documents are PDF? Are the Archives going to have to maintain Acrobat Reader? That’s why we say we’re available in human-readable form.
Mr. Royal: If you can find the specification that was used when it was generated.
Mr. Gorman: That’s what the W3C is for.
Mr. Ambur: This functionality needs to be a commodity built into myriad pieces of software. I agree that it should be based upon an open standard that is built into multiple products, but it also has be be capable of binding presentation and content together for legal purposes. And that’s the reality technologists are running away from.
Mr. Royal: Owen and I have healthy debates. I respect his opinion. We don’t agree on everything. To me, forms are temporary. Whether by interview, paper, or electronic means, you get the data. Once you preserve context (date, certifying entity, etc.)—once that’s preserved, it’s valid regardless of presentation.
Mr. Gorman: Those are valid points, but there are other requirements outside of that. Someone like the Air Force might say, “Hey listen…”
Mr. Royal: Because we’re tied to the paper world by history, and because that’s the way we’ve done it.
Mr. Gorman: I’m not the oldest guy in the room, but if I buy a book, I want the book—not the CD for it, but for other purposes, paper is a pain. That’s part of the reason GPEA is around.
Mr. Royal: In the right format, I can store in whatever medium I want.
Mr. Gorman: The last three bullets on this slide address what the viewer does: it has a computational engine, small file sizes, and full control for the user. Forms are dynamic. They respond to the input. You’re right—forms are a pain. That’s difficult. We looked at Air Force forms, for example a “leave” form. It was two pages long, a pain. We compressed it to about four wizard screens, where you answer a simple question, and pre-populated it with data.
Mr. Royal: You call it a form. I call it a user interface.
Ms. Watkins-Taylor: It’s an “information management tool,” not a form anymore.
Mr. Gorman: We call it the front end because you have business processes, with data in the back end. It makes a total solution.
Slide 11 [Building Web-Enabled Applications]: In the Air Force case, this means eliminating as much paper as possible. You have a common portal—a place to get forms when you need them. It’s saved a bunch of time. They save $3 million a year just on filling out forms. We have the ICS Viewer, ICS Designer, ICS Enhanced APIs, and ICS Deployment.
The viewer is the presentation. ICS is an Internet commerce suite. APIs are a toolset. You build them or we build them for you to solve problems. The deployment server is a tool to automate the deployment of the viewer. If you open an XFD, it looks to see if you have the viewer and downloads it if needed. It’s optional.
Mr. Savage: On API, if you publish tag names, does the API let you go in and extract data from a form?
Mr. Gorman: We say it either takes or puts information into the form. It allows you to collect all or a subset of the data, and do with it as you choose, so if you’re a company with an Oracle application, and you want to glean information from the form, the API lets you.
Mr. Royal: If I have an XML document with name, address, etc. in a standalone file to pre fill the form, would I use that API?
Mr. Gorman: I’m not familiar with it, but I would say yes with this caveat: Software AG has their Tamino database. It’s an XML database, and we integrate smoothly with them.
Mr. Royal: Does it interface through DBMS, or XQL, or…
Mr. Gorman: Let’s hold off on that for a moment.
Mr. Savage: We’re going to come back to that with you [PureEdge].
Mr. Gorman: I can’t tell you exactly the nuts and bolts of API.
Slide 12 [Web Ap Architecture]: It would look like you’d use the designer to create an e-form. You’d use a servelet to store it, and you can save it in an archive system. Again, it’s a legal record because it’s the whole thing.
Slide 13 [Robust Features]: Open standard, open standard, open standard, is the whole thing. Platform independence. It creates exact replication of the document. Very powerful layout. We have a compute engine that computes calculations of data without refreshing. We also have validations on fields. It also has dynamic customization of the form behavior. That’s important because, why look at if you don’t need it or can key in a profile and it does it for you? We also comply with Section 508. We use JAWS. It’s part of the form. It’s why the viewer is so important, because the logic is behind the viewer.
Slide 14 [Robust Features (continued)]: It has good help screens, customizable to the user. It uses drag and drop signature controls—it takes about 30 seconds for the signatures. It allows multiple and overlapping signatures. For example, you sign a document and send it to the boss, who signs it. So for each person who signs it, it protects his comments. You can’t change any layer of the signature that’s applied. It’s all part of this one unit that we call the “document.”
It also integrates with external data sources. Easy integration with best-of-breed document management. If you’re working with it and you have some sort of management system, we work with it.
Slide 15 [Select Customers]: Here are some of our higher profile customers. Since we’re Canadian-based, we’ve done a lot of work with large organizations in Canada.
Slide 16 [Technology Partners]: This is to show that we’re not alone. We have integration and technical partners. We like to talk about being vendor-neutral. We don’t care where the signature came from. We also provide signature filtering. In the case of the Air Force, say, the only one who can sign a particular form has to have DoD Class 3 certification. We can assure that you have the right certification. It’s an important element of the product.
Slide 17 [Select Federal References]: These are here for when you want to take a look at our product..
Slide 18 [Next Steps]: What do we do when you say you want the product? We:
Slide 19 [Thanks!]: So in summary, I’m Will Gorman and I’m the Field Sales Engineer for the federal government and the East Coast. I’d like to thank everyone for your time and attention.
Ms. Yang: Did you talk about Math XML in your design?
Mr. Gorman: I can’t explain it well, but it can be used. One of our demonstrations shows the game of “21.” We are not limited to it, but if you need to use it, we could work with it. Computation is very important. John Boyer wrote the computational engine.
Mr. McKennirey: How do you decide whether to accept certifications?
Mr. Gorman: We have a filtering tool.
Mr. McKennirey: Something inside the XFDL…?
Mr. Gorman: We work with CAPI. It looks into storage at what’s held and brings back what’s valid. It’s accounted for in the design phase. The answer is yes.
Mr. Lyman: It’s done by IFX, so in the Air Force viewer it’s IFX 150K. Our viewer has a great many of these IFXs. It’s like a “config” file. The viewer isn’t like what you think of as a viewer—for instance, if you don’t want the buttons the Army or Navy has, you can define how it appears.
Mr. McKennirey: How can you change them?
Mr. Lyman: Through a deployment server, or deployment package—like the Air Force’s was AF5.1 We built it manually because the Air Force has one, but if you want to use a deployment server, you can do that.
Mr. Gorman: A deployment server looks at your viewer and says “yes or no.” IFX is a viewer standard. The Air Force had that requirement, so we built it for them. You may not have that requirement, so that’s OK. Some things are form-based, some are servelet-based, some are API-based.
Mr. Ambur: Then in reference to the FEA Service Component Reference Model, those are components that can be reused?
Mr. Gorman: Exactly. We don’t have to reinvent the wheel. Instead of charging you to reuse, you can say, “We already have it.”
End Presentation
Mr. Ambur: If there are no other questions, the next speaker is Rick Rogers of Fenestra. Rick is on the phone. Rick, would you like to give us a quick rundown of the Web Services Working Group’s eForms incubator project?
Mr. Rick Rogers: Yes. What we’re doing is working under the XML WSWG. We formed a pilot group to investigate e-forms for EGov. Our main goal is to figure out and recommend what standards for e-forms there are that the government might wish to use in its architectural plans and describe those standards. We also decided to pick between six and twelve government forms and develop examples of using the standards with the forms. The standards are like SVG, XForms, and XSchema, published by W3C. We’ll take a handful and develop documents that comply and post them on a website for the general public to look at, so people can see how the standard translates.
That’s the first step. The second is to invite vendors to use forms to show how the various products will work with the forms. We’ll publish information from vendors in our presentations.
Mr. Ambur: Will, I hope you took note of that.
Mr. Rogers: Someone from PureEdge has contacted me via email. That’s the second step. The third is to analyze where standards have gaps in satisfying federal requirements and make recommendations to standards committees on filling them, particularly in drafting changes to gaps. Since we’re chartered under the WSWG [http://xml.gov/documents/completed/wswg/eformcharter.htm], we hope to describe some of the Web Services operations to use to automate work flow of e-forms. We’re setting up a regular meeting time, and we invite all who want to participate to send me an email at rick@fenesta.com. If you send me a note, I’ll send you a message to let you know where we’ll be publishing this.
Mr. Royal: Has there been any interest from Microsoft?
Mr. Rogers: Yes. Susie Adams is there. She’s been interested. She believes their XDocs product supports some of the standard, so they’re interested in particular in the pilot and using some of the products.
Mr. Brand Niemann: She was scheduled to present on that yesterday at the WSWG meeting. I’ll post her presentation soon. We’re planning to have a whole day on Web Services for enterprise architecture on the 17th.
Mr. Royal: Have you already selected the forms?
Mr. Rogers: We’re still in the process, in the conceptual framework. We want to select a citizen-centric form that a citizen would do to get services with the government; then a business-related form, etc.. We have some categories. If anyone has any categories to suggest, please send them to me.
Mr. Niemann: Let me add that three EGov initiatives—e-grants, EGov benefits, and Rulemaking have asked us to help with forms. We’re the farthest with e-grants, and there’s a summary on Slide 10 at the Web Services website. Rick had a breakthrough in finding schemas for XF424 from an associate of his.
Mr. Royal: GSA developed schema for a number of forms there. I don’t know how much research it took. In our XML.gov archive, you can probably find a helpful tag study. Our contractor found several forms that had common data elements you might be able to use.
Mr. Rogers: We’re developing a schema for the forms. We’ll be registering it in the XML collaboration registry that you can find at the Web Services site. We’re probably going to independently create the form and register, but if someone has a better way, I’d be happy to hear about it.
Mr. Ambur: I’ll send you the URL for the tag study that Marion mentioned.
[Editor’s note: It is available at http://xml.gov/documents/completed/tagreport.pdf.]
Marc, would you like to give us an update on your XRI work?
Mr. Marc Le Maitre: It’s interesting to note that a couple people mentioned reuse of objects and resources. I’m also not one for reinvention. I hope to combine some work I committed to doing for Marion on definitions of namespace syntax with contributions to the XRI TC [OASIS Extensible Resource Identifier Technical Committee].
For a brief update on the last two months, since I spoke about XNS and the XRI TC at the Working Group meeting— the TC has now completed the charter, and had two meetings over the phone. We’re having a face-to-face meeting over the next two days in San Francisco. Our initial work is the comparison/contrasts to other ID schemes to show where we fit and work. Some of note are: URI, URN, Handle, DOI, RDF, Semantic Web and its use of metadata, Topic Maps, Secure Grid Naming Protocol, AutoID, XQuery, and XPath. They’ll all be worked on over the next two days. I hope to make the output available to the XML Working Group.
There are a couple areas where I’d like some input, either now or via email: the first is use cases and requirements. I propose to create some of them to address specific government initiatives--like the GSA XML registry/repository to define the use of XRI identifiers for a federated XML repository. The second would be the use of XRIs in the eAuthentication service. We hope to output some requirements documents to explain the challenges and solutions for ID schemes in registry/repository and authentication. We need to know, if we were to do this work in the XRI TC, would those be the ones you want us to work on? We’re looking for feedback from this group. The second thing is how to ensure accuracy of input from you guys, how to gather feedback from the various work groups and accurately reflect the requirements, how to coordinate properly, and how to present XRI TC output—EGov technical committee, XML Working Group, or both?
Mr. Royal: My quick vote is both.
Mr. Le Maitre: OK, I’ll work with Owen to schedule a time ahead to feed that back formally. We’re also wondering whether there are other initiatives that have requirements that the XRI TC can answer? We’re interested in the Commerce Department’s announcement to support ENUM. There was a specific quote about an ID scheme in ENUM to support Internet and telephony IDs and to protect privacy in consumer information. We don’t have contacts there, but I think we could assist in writing the requirements to support a federated ID space. I’d very much like to hear feedback on whether we’re working in the right direction to support work on ID schemes in the federal government.
Mr. Royal: I need to catch up with you because I haven’t followed your work closely, but you’ve been speaking about how useful it is, so I’ll hold my thoughts until we speak.
Mr. Le Maitre: I’ll send you an outline of the top 10 requirements as we’ve defined them in our group in OASIS. Maybe next week I’ll come back and talk to you about it. I’d be happy to pop in and see you if want to get a small group together.
Mr. Ambur: You problably know the OASIS e-Gov Technical Committee is scheduled to meet in Washington on March 12.
Mr. Le Maitre: Do you think there’s an opportunity to speak there?
Mr. Ambur: I doubt there will be much opportunity to speak, but Diane Lewis of the Department of Justice is heading up the requirements subcommittee. Justice has an even bigger interest in IDs than the rest of us do. Maybe you could touch base with her to see whether she might like to write something into her subcommittee’s charter.
Mr. Royal: The e-Gov committee needs to look quickly at establishing liaisons with the EGov committees of other standards organizations.
Mr. Le Maitre: My arms are open to that. I’ll talk to Diane about that.
Mr. Royal: My colleague David Layton is working with e-Gov and ebXML. There are some opportunities there.
Mr. Le Maitre: John Evdemon of Booz Allen has been actively working on the e-Gov mailing list. This is relevant, because BAH performed the business case analysis for the GSA XML Registry/Repository. How do I find the latest work on that? My latest is several months old.
Mr. Royal: They did a business analysis—not schema development or standards—for the Registry/Repository. NIST has done some. Roy, you’re here.
Mr. Roy Morgan: On the registry work, we will be establishing a new proof-of-concept registry at NIST in support of this group. We're moving money now, and we have a server that's getting brought up. The repository is being brought up with the commercial GoXML product and will function as a testbed. We expect to have a demonstration next month at this meeting.
Mr. Le Maitre: The business standards work would be helpful to me, because we’re trying to address the challenges. We’d like to justify the business case analysis for looking at the requirements.
Mr. Royal: Stay tuned to XML.gov.
Mr. Le Maitre: If you can share it with me beforehand, I’d appreciate it.
[Editor’s note: The business case for the XML registry is now available at http://xml.gov/documents/completed/bah/registryBusinessCase.htm.]
Mr. Ambur: Any other comments or suggestions? Bruce [Bargmeyer], are you on the line?
Mr. Bruce Bargmeyer: Yes. The Open Forum went off as planned. We missed Marion. I’m sorry you weren’t able to come. About 250 people came, and 70 to associated meetings, so it amounted to over 300 people. From what I understand, the content of the presentations was good. We got the chair of the OASIS Registry/Repository Committee together with chair of the OASIS UDDI committee. They’d never met in person. I think we made progress. Folks were energized enough that they created ad hoc meetings on the fly during lunch to talk about how registries would go together, so the feedback was that it was successful and good progress made
Mr. Royal: Some of that conversation is still going on on the Registry/Repository listserve and others.
Mr. Bargmeyer: Since it’s late, I’ll hold my report to that.
Mr. Ambur: Bruce, are the presentations available on the website?
Mr. Bargmeyer: They’re available. Currently they’re not in the organized fashion I’d like. I’ve rounded them up from all the sources and put them there under the “Presentation” directory. I’ll sort by presenter and organize by track.
Mr. Ambur: As soon as you have the URL, I’d like to feature it on the XML.gov site in the What’s New section.
Roy, would you like to make an announcement about your meeting?
Mr. Morgan: I’d intended to have a brief summary and status update at this meeting. We haven’t scheduled a full meeting for this afternoon.
[Mr. Morgan briefly described the Registry/Repository work.]
Mr. Ambur: Very good. I thank you all then.
[Editor’s note: Mr. Abraham Coy arrived just at the meeting was breaking up. He conducted his briefing for a few folks who stayed to hear it. The dialogue was not captured for these minutes, but his presentation on the Air Force’s forms automation project is available at http://xml.gov/presentations/usaf/eforms.pdf .]
Attendees:
|
Last Name |
First Name |
Organization |
|
Ambur |
Owen |
FWS |
|
Barr |
Annie |
GSA |
|
Connelly |
David |
OAGI |
|
Ellis |
Lee |
GSA |
|
Gorman |
William |
PureEdge |
|
Le Maitre |
Marc |
One Name |
|
Lyman |
Bruce |
EIM |
|
McKennirey |
Matthew |
Conclusive |
|
Morgan |
Roy |
NIST |
|
Niemann |
Brand |
EPA |
|
Rogers |
Rick |
Fenestra |
|
Royal |
Marion |
GSA |
|
Savage |
Robert (Doc) |
AFCA |
|
Schaefer |
Barry |
|
|
Swearingen |
Sandra |
USAF |
|
Thurston |
Keith |
GSA |
|
Troutman |
Bruce |
8020 Data |
|
Vanatta |
David |
Lockheed Martin |
|
Watkins-Taylor |
Carolyn |
AFDPO |
|
Weber |
Lisa |
NARA |
|
Yang |
Carol |
US PTO |
|
Yee |
Theresa |
LMI |