XML Community of Practice
Meeting Notes
June 15, 2005
The Internal Revenue Service (IRS) hosted this meeting at Computer Science Corporation’s (CSC) Maryland Technology Center.
Owen Ambur announced that Charles Nethaway has volunteered to lead a community of practice to specify Strategy Markup Language (StratML). As soon as the group has identified a collaborative space, a link will be established at http://et.gov/stage2.htm
Owen displayed the ET.gov site, particularly the search results screen – http://et.gov/component_search.aspx – and indicated that XML-related components registered there are candidates for consideration at future meetings of the xmlCoP. In the meantime, thought should be given to whether and, if so, how best the xmlCoP may be able to foster the formation of CoPs around any of those proposed components.
Tim Mathews briefed the group on the draft update to the XML Developers Guide, suggesting that priority consideration should be given to the issues of modularity, namespaces, and versioning. Loren Osborn suggested that a glossary is needed to define terms used in the Guide and Tim agreed. Someone observed that the draft does not presently reference the Federal Enterprise Architecture (FEA) Data Reference Model (DRM) and vice versa, and Owen indicated his understanding that it is the intention to do so. Additional points of discussion included:
Changing the title of Figure 1 to Table 1.
Including the token value “STA” in Table 1 to designate Standard Adherence guidelines.
The meaning of de jure with respect to voluntary consensus standards in STR1.
With reference to STR3, Tim suggested the only reason the term SHOULD rather than MUST is proposed is because it is unclear where agencies would be expected to promote XML components for establishment as voluntary consensus standards.
Regarding STA2, Joe Chiusano and KC Morris asked how conformance with the W3C suite of recommended technical specifications can be tested.
Use of the term MUST in STA3 conflicts with the suggestion in the paragraph preceding it that proprietary extensions should not be employed.
In the paragraph immediately below Figure 2-2, Joe recommended changing the word “semantic” to “class” and Loren Osborn suggested that OWL should be referenced if semantics or notation are mentioned. Sol Safran suggested that this kind of information is important and he noted the CCTS is an international standard.
Consensus appeared to exist on changing the word “Semantic” to “Class” in the title of Figure 2-3 as well as Figure 2-2.
With reference to Figure 2-4, Todd Vincent noted that modularity affects how the figure should be depicted, and he proposed a 1-to-1 relationship between Object Class and an XML schema.
Someone noted that ISO 11179 is syntax-neutral but Joe suggested it is not necessary to consider ISO 11179. Instead, he suggested just stating the XML naming and design guidelines, perhaps with an appendix or separate mapping to ISO 11179. Todd agreed that data modeling follows naturally if the naming and design rules are properly specified.
Joe suggested that Figure 3-1 should be simplified, and Owen agreed. Tim asked whether the group felt that a URL should be provided for each Complex Data Elements Schema Module. Todd spoke of the need for modules for reference documents. He drew an analogy to Legos and suggested that a building block directory is needed; otherwise schema get too large. Tim mentioned cascading include and import statements, but noted the version management problem associated with large numbers of components. Todd argued that it is bad practice to allow subdocuments to be changed without affecting the root schema, and he suggested the issue of whether to use URLs or URNs can be separated from the issue of version control for minor changes to XSDs. He expressed the belief that version control can be addressed with unique namespaces and that doing so enables the use of small schema.
With further reference to Figure 3-1, Tim suggested that the modules for source standards qualified and unqualified data type schema are very important, but Todd noted the W3C XSD specification already includes some data types and questioned the justification for CCTS core component types. Tim responded that the short answer is that they are needed to facilitate interoperability. He noted CCTS specifies 10 primary and 10 secondary types, but he also said CCTS plus supplementary components still do not contain enough semantics without data types. Todd indicated he still did not understand, and that it appeared to be Germanization of the names but that it is not a big point as far as he is concerned. Tim also noted that LMI’s testing indicated system performance degradations from using include include versus import statements.
Joe suggested this entire section may be out of the scope of this document, but the DRM may address significant parts of it.
KC and Owen noted that the word “created” should be changed to “used” in SSM 10, 12 and 14.
With respect to section 3.6.4.1, relating to agency complex data element schema modules, Vicky Niblett asked where agencies can find them. Tim suggested CORE.gov may become the repository, and Todd suggested that publication rules are needed.
Referencing SSM20, Sol asked if there is an official list of government agencies. Loren asked whether, for example, DoD as a whole is considered to be a single agency or whether the armed services branches would each be considered to be a separate agency. He noted that section 3.4.2 provides a listing but questioned whether it is complete and authoritative. Tim noted that a domain registration system already exists for URIs.
With reference to GXS2, KC questioned the need for two normative schemas for each transaction, since run-time versions can be automatically derived from the fully annotated versions. Consensus appeared to exist on that point.
Regarding DOC5, KC questioned the logic of capturing structured metadata in an unstructured xsd:documentation element. Noting that the word MUST has been proposed, indicating that this information must be provided, Owen said he will not agree to try to mandate something that cannot be measured, and he suggested the proposed mandatory sub-elements of this element should be promoted to machine-processable metadata elements. Tim indicated the discussion tended to suggest that the document will be more of a guide than a set of rules and Owen agreed, noting that is how he has described the document anyway, i.e., as an XML developers guide rather than a set of naming and design rules. Todd noted that he has an XSD that ignores the rest of other XSDs that it validates and only checks the documentation elements.
Time did not permit review and discussion of the entire draft document. It was agreed that further discussion would occur on the listserv and that the agenda of the July 20 meeting of the xmlCoP would focus again on this topic, with the hope of completing the discussion and achieving substantial consensus on all of the significant aspects of the draft.
The draft is available at https://fed-xml-ndr.core.gov/servlets/ProjectDocumentList?folderID=606&expandFolder=606&folderID=0 and the listserv archives are at https://fed-xml-ndr.core.gov/servlets/SummarizeList?listName=listserv
Among those in physical attendance were:
Owen Ambur, xmlCoP
Don Bev, Treasury/FMS
Joe Chiusano, BAH
Albina Delozier, IRS
Juan Goldstrom, IRS
Puja Goyal, NIST
David Levine, IRS
Josh Lubell, NIST
Tim Mathews, LMI
Meribeth Miller, IRS
KC Morris, NIST
Vicki Niblett, SAIC/NASA
Loren Osborn, Unicorn
Doug Peterson, IRS
Sol Safran, IRS
John Triplett, IRS
Lou Yeu-Hsiung, CSC/IRS Prime
Among those who identified themselves as participating via teleconference were:
Todd Vincent, Legal XML
Brenda Duvall, CSC
Sylvia Webb, GEFEG
John Weiland, NMIMC/Navy
Please convey any additions or corrections to Owen_Ambur@ios.doi.gov