XML Task Group TG1 Transportation Subcommittee (X12I) Monday, 1 June, 2009 Cincinnati, OH. 3 Disapproved with comment.

Transcription

1 XML Task Group TG1 Transportation Subcommittee (X12I) Monday, 1 June, 2009 Cincinnati, OH ASC X12I/TG1/ MEETING OPEN X12I/TG1-XML met on Monday, 1 June at about 13:30 EDT. The task group chair, Dana Morton, FedEx, convened the meeting and made brief introductory remarks via teleconference/gotomeeting. Nineteen participants introduced themselves, seven of those dialing in via teleconference capabilities. They approved the minutes from the January meeting in Portland without change. REFERRED DATA MAINTENANCE TG1 reviewed 22 referred DMs that are related to CICA/XML, with the following disposition: 19 Deferred 3 Disapproved with comment. Table 1 below summarizes TG1 s position on the DMs referred to X12I. Table 1. X12I/TG1 Disposition of Referred DMs DM number Deferred Deferred Deferred Deferred Deferred Deferred Deferred Deferred Deferred Deferred Deferred Deferred TG1 XML 1

2 Table 1. X12I/TG1 Disposition of Referred DMs DM number Deferred Deferred Deferred Deferred TG1 XML Disapproved with comment a Disapproved with comment b Disapproved with comment c Deferred Deferred Deferred a Comment for DM : The submitter has apparently not input the changes requested by TAS into the CHM file. b Comment for DM : The changes requested by TAS apparently have not been input into the CHM file. c Comment for DM : Adding quantities to a block designed to convey equipment information is not appropriate; doing so violates the rule for blocks that each block have a single purpose. DISCUSSION OF DATA MAINTENANCE AND RELATED CICA ARCHITECTURE AND DESIGN RULES CHANGES Discussion ensued regarding how long an open DM is maintained on the referral letters. Tom Bolling, NS Railroad, explained that the coordinating subcommittee owns the DM once it is opened, and the only way to remove a DM is for either the submitter or the coordinating subcommittee to withdraw the DM. Mr. Bolling questioned the Barge community to ensure that implementation of DM would be functionally different from a Functional Acknowledgement (997) or an Application Advice (824) transaction set. Matt Heironimus, Cornerstone Solutions Group, noted that TG4 may withdraw this DM, but if it continues forward, he assured Mr. Bolling that TG4 understood the differences, and the resulting message would be functionally unique. Mr. Bolling recommended that as long as the data conveyed was business- (vs. syntactically-) oriented, there shouldn t be a problem. Ms. Morton led a discussion of DM At the January trimester meeting, TG1 advanced three proposals to modify the CICA architecture and design rules. Ms. Morton expressed her opinion that it was not likely that TG1 s proposal to eliminate blocks from the CICA architecture would be approved. June Arnold, BNSF Rail, countered that recent membership changes have lead to more open-minded approaches and attitudes about the architecture. 2

3 Discussion Regarding Proposal #1 Proposal #1: X12I/TG1 proposes that the CICA architecture be modified so that Any child construct MAY inherit its identity from its parent construct. CICA design rules require that blocks have a unique identity. This results in data that is not necessary from a functional business process being included in CICA-based schemas. Proposal #1 suggests that if a block is within an assembly, the block might inherit its identity from the assembly. As an example, if a block is used to convey an equipment description, its identity might include such data as its color, weight, volume, etc. There is no functional business requirement to convey these characteristics every time the block is used in an instance document. Discussion Regarding Proposal #2 Proposal #2: X12I/TG1 proposed that the CICA architecture and design rules be modified to eliminate blocks and modules, and retain assemblies, primitives, and components. As discussion ensued, members noted that modules and assemblies are essentially the same type of construct, but used to fulfill different functionality. X12C appears to agree with this evaluation. This proposal might be combined within DM , submitted by Peter Pruyne. That DM proposes changing the CICA architecture to flatten the resulting schemas. Mr. Bolling said that a major problem with blocks in the CICA architecture is that each block can only be used for a single purpose. He indicated that blocks are roughly analogous to segments in EDI transaction sets. When sending EDI documents, all the data elements defined in each segment are not necessarily sent with each instance of the segment element usage is dependant upon the functional purpose of the segment in a specific context. Members of the task group went on to discuss the different requirements for document design criteria and transmission (exchange) criteria, with Mr. Bolling noting that the design criteria are sometimes focused on encouraging reuse of elements, but that appears to be causing a (perceived) impediment to trading partners willing to implement CICA-based schema. Discussion Regarding Proposals #3 and #4 The task group modified the change proposals slightly to clarify the differences between the facets proposal and the abstracts proposal. 3

4 PROPOSAL #3 DISCUSSION Proposal #3: The task group proposed that facets should only be sent when the data they convey is needed. Ms. Arnold proposed this wording: Do not show/send facets if they don t add any business value electronically to the transaction payload. Ms. Arnold noted that in actual practice, very few, if any, facets would be used in a payload document; she suggested we eliminate the facets from the schemas. As an example, she noted that every text field had a language facet, but was not aware of any documents in which the language specified would change from one text field to another. Frank Napoli, LMI, questioned whether it might be possible to declare such a facet as global and have it apply to an entire document. Mr. Bolling clarified the intent of the proposal that only those facets that are functionally necessary in a particular context be sent in a payload document. PROPOSAL #4 DISCUSSION Proposal #4: TG1 recommends the removal of abstracts from the CICA architecture. The proposal passed unopposed. The task group went on to discuss removal of abstracts from the CICA architecture. Points raised during the discussion included the following: Abstracts do not convey useable data in a payload. They are an architecture construct to increase reuse. Abstracts such as Resource_ID_1 and Resource_ID_2 provide no benefit what level of abstraction is sufficient? To quickly develop a new document, you need a cheat sheet of generic concepts to start from. Abstracts, as currently defined, do not fulfill this need. Reusable constructs such as City, State, and Country that are always the same are absolutely needed across all documents. We need a definition of an abstract X12.71 defines an abstract component, an abstract primitive, and abstract assembly, etc., but we could not find a definition of an abstract. General discussion ensued noting that the primary purpose of abstract constructs is to encourage reuse of the constructs. Mr. Bolling emphasized that this proposal is more focused on design (as opposed to implementation) issues. Ms. Morton suggested that during our joint meeting with X12C on Tuesday at 1:00 PM EDT, we need to discuss the question of how to come to consensus across all of X12 on ways to improve the CICA architecture and design rules. 4

5 NEW BUSINESS TG1 will hold a joint meeting with X12C on Tuesday, 2 June at 13:00 EDT to discuss TG1 s proposals to change the CICA architecture and design rules. Discussion ensued in preparation for that joint meeting. The discussion with X12C will focus on the four change proposals TG1 developed at the January trimester meeting. As indicated above, members agreed that the header for change proposal #4 should be moved up above the bulleted list related to removal of abstracts. Discussion in Preparation for Joint X12I/X12C Meeting X12I chair, Doug Anderson, Kleinschmidt, reported that X12C had submitted a request to the Steering Committee to remove blocks from the CICA architecture. Mr. Anderson reported that the informal initial response from the steering committee was not favorable. The steering committee made the point that a desire to align the CICA standard with other standards does not override the current design criteria. There was no other new business. MEETING ADJOURNMENT Ms. Morton adjourned the meeting at about 15:25 EDT. Respectfully submitted, Frank B. Napoli, Acting Secretary 5

6 MEETING OPEN INTRODUCTIONS XML Task Group TG1 Transportation Subcommittee (X12I) Joint Meeting with X12C Tuesday, 2 June 2009 Cincinnati, OH [Editor s note: These informal meeting notes are not official minutes; The official record of this meeting will by published by X12C.] Mike Rawlins, X12C, called the meeting to order at approximately 13:00 EDT. Official minutes for this meeting will be provided by X12C, these informal minutes are provided for internal X12I/TG1 use. The meeting participants introduced themselves. These members of X12I/TG1 were physically present: Doug Anderson, Tom Bolling, Matt Heironimus, Bob Murgatroyd, Frank Napoli, Bruce Ramsden, Kala Shihady, and Pete Varone. These members of X12I/TG1 participated via teleconference call: June Arnold, Rita Marie Cimini, Betty Kuch, Dana Morton, and Jim Taylor. These members of X12C were physically present: Tommy Lyons, Nat Obey, Peter Pruyne, Mike Rawlins (acting chair), and Bill (?). PROBLEM DISCUSSION Dana Morton, FedEx and X12I/TG1 chair, began the discussion by stating that transportation trading partners (TPs), in general, find the CICA-based schemas too complicated to implement; she said that X12I/TG1 had three proposals to address that (perceived) issue. At the highest level, Ms. Morton said the issue is that the CICA architecture requires that all the CICA data be exchanged in the payload document, whether there was a functional business requirement for that data or not. June Arnold, BNSF Railway Co., concurred with Ms. Morton, saying that BNSF s TPs asked them to get rid of unnecessary data from the CICA schemas, and in some cases provided alternate schemas that they required BNSF to use in place of the CICA schemas. 6

7 Proposition #1: Proposition #2 Proposition #3 Tom Bolling, NS Railroad, suggested that the issues result from design, rather than business implementation requirements; Ms. Morton concurred. Mr. Rawlins said he was hearing several problems enumerated, some of which were related to X12.7, and some that were not. The participants began to discuss X12I/TG1 s Propositions (see text of the proposals, above.) After a high-level discussion of proposition #1, Mr. Rawlins said that in certain circumstances where identity is implied by other constructs, he saw no problem with allowing a block not to include identity. Discussion of proposition #2 ensued. Participants agreed that the elimination of blocks and modules were two separate issues, and agreed to separate the elimination of modules from proposition #2, and consider it as a new proposition #5. Mr. Rawlins asked why blocks were problematic in this context. Ms. Morton explained that because the CICA design rules require that a block convey a single unique meaning, a single block could not encompass two different concepts. Mr. Bolling said the rail industry had run into this issue when it was designing the Rail Price Distribution transaction the CICA design rules precluded a single block from conveying both a price and the effective date range for that price. That resulted in needing to use two blocks to convey what effectively is a single business requirement. Mr. Rawlins began consideration of proposition #3 by asking if the proposition really referred to supplementary components rather than facets. Ms. Morton agreed that the intention was to refer to supplementary components. She gave an example of the problem with the current implementation of the supplementary components: Currently, CICA design rules require that a language must be specified for each occurrence of a text field. This requirement results in including English each time a text field is specified. Mr. Rawlins replied that a supplementary component could be marked not used, and it would not show up in the resulting schema. Discussion ensued regarding whether the GEFEG editor or the CHM file itself supported marking the supplementary components as unused. Ms. Morton said she would work with Mr. Rawlins to research this question. Mr. Rawlins asked if, assuming the GEFEG editor and the CHM file support this functionality, this is a satisfactory response to proposition #3, and Ms. Morton agreed that it is. 7

8 Proposition #4 Proposal #5 NEXT STEPS Mr. Heironimus accepted the action item to investigate how to set global defaults for such attributes as language and currency. Ms. Morton observed that over time as the CICA architecture and design rules have evolved, abstract constructs have become less abstract; she suggested we remove them from the CICA architecture. Mr. Rawlins said he understood the intent of this proposal. Mr. Bolling noted that this is a design, not an implementation, issue; Mr. Heironimus added that from an implementation perspective, using abstracts is busy work. Discussion ensued regarding whether the use of abstracts simplifies the process of finding reusable constructs when creating a new CICA-based document. Ms Morton agreed that X12I/TG1 would accept the action item to research alternate methods for developers to find reusable constructs when building new documents. The participants agreed to create a new, proposal #5, which is to eliminate modules from the CICA architecture. This proposal was split off from the original proposal #3, to allow separate tracking of the proposals to eliminate both blocks (proposal #3) and modules (proposal #5.) Ms. Arnold noted that assemblies and modules are similar enough that both are not necessary in the architecture with some minor modifications, assemblies could be used to provide the functionality currently provided by modules. Mr. Pruyne proposed the changes summarized below as a way of addressing the issues X12I/TG1 brought to X12C. Mr. Rawlins said that X12C has a good understanding of the issues X12I/TG1 wanted to address, and its proposals to address them. He said that X12C would undertake a comprehensive review of the proposals, as well as Mr. Pruyne s proposals, and publish a formal response of X12C s proposed way forward. Mr. Rawlins asked Doug Anders, chair of X12I, if he had any additional remarks, and as he did not, Mr. Rawlins adjourned the joint session at about 3:30 PM EDT. 8

9 PETER PRUYNE S PROPOSAL Peter Pruyne, X12C, proposed the following response to X12I/TG1 s proposals. DM Peter Pruyne s Alternate Proposal Notes Items highlighted in yellow have been added by X12C and/or X12I. 1. Change summary a. Remove blocks, modules, and components b. Levels remaining: primitive, assembly, template, document, and slots c. Add flags to indicate blockness and moduleness i) Block flag indicates the assembly meets the current rules for blocks. ii) Module flag indicates the assembly is used to fill a slot in a template (i.e., this is complete enough to satisfy a major business messaging need ) d. Existing blocks become assemblies with block flag set e. Existing modules become assemblies with module flag set f. Existing components become assemblies 2. Compatibility advantages a. All existing constructs remain valid b. Infrastructure, process, and design rule changes are small 3. Document changes a. X12.7 Remove sections, modify existing sections b. X12.71 Remove block construction requirements, change singleness to about setting block flag 9