XML Community of Practice

Meeting Notes

March 15, 2006


This meeting was hosted by the National Institutes of Standards and Technology (NIST) at its campus in Gaithersburg, MD, in conjunction with Interoperability Week. Simon Frechette welcomed the group to NIST and to the Interoperability Week activities. The group introduced themselves and their interests in XML.


Owen Ambur announced that Charlie Havekost, CIO of HHS, and Lisa Schlosser, CIO of HUD, are the new co-chairs of the CIO Council’s Architecture and Infrastructure Committee (AIC). They plan to form an new subcommittee focusing on the Federal Enterprise Architecture (FEA) Data Reference Model (DRM) and to rename the Components Subcommittee as the Services Subcommittee, thus redirecting its focus on services that are ready and available for reuse. Version 3.5 of the executive management strategy for the Service Component Based Architecture (SCBA) was recently released and is consistent with Charlie and Lisa’s plans for the new Services Subcommittee. The draft business case for Strategy Markup Language (StratML) is nearing completion for presentation to the AIC. Adam Schwartz of the Government Printing Office (GPO) is heading up the StratML community of practice (CoP) and welcomes participation.


Owen also noted that he would be speaking at the FedCASIC conference at the Bureau of Labor Statistics (BLS) on March 16. He mentioned XMP Open day, scheduled for March 22, and expressed hope that someone would register XMP Open at ET.gov as a proposed specification for inclusion in the FEA Technical Reference Model (TRM). He called attention to the workshop on PDF and XML that CENDI is hosting at the Department of Energy on April 6. With reference to upcoming meetings of the xmlCoP, he noted the April meeting will be conducted as an open town hall meeting at the Knowledge Management (KM) conference at the Reagan Building on April 20, and the May 17 meeting may be held in conjunction with AIIM’s C30 committee meeting in Philadelphia. Another possibility for the may 17 meeting is an agenda focused once again on XML registry services. The office of Federal Student Aid (FSA) has offered to host another meeting on registry services, either in May or on the xmlCoP’s June 21 meeting date. Owen expressed is understanding that the next release of DoD’s XML registry will be ebXML compliant, and since FSA’s registry already is, it would be interesting to see if they can interoperate.


Finally, Owen noted that Betty Harvey’s DC Area XML User Group would be meeting that evening (March 15), with presentations on RDF and XACML.


KC Morris briefed the group on lessons learned from encoding the Department of the Navy’s (DON) XML Naming and Design Rules (NDR), suggesting that encoding rules for testing results in the development of better rules. She also noted that most of the rules and guidelines in the xmlCoP’s draft Naming and Design Rules and Guidelines (NDRG) are not testable. In some cases, external interfaces are assumed and the NDRG cannot be tested without them. With respect to the definitions of terms, for example, KC observed that while the Oxford English Dictionary (OED) does not have an online interface, other dictionaries do. As one example of how the draft NDRG are currently unworkable, Betty Harvey noted that empty elements, which would be prohibited, are required in many instances, e.g., for attachments and revision tracking. Bruce Cox suggested that it will not be acceptable to have different rules for data versus documents. Sol Safran suggested that folks focusing on documents should draft NDR, as the data folks have, but Bruce argued the differences do not constitute a mountain but, rather, a hill that we need to get over.


KC’s presentation, which is available at http://xml.gov/presentations/nist5/donndr.htm, was followed by a demonstration of NIST’s quality of design tool by Serm Kulvatunyou. He suggested that test profiles be developed, such as for documents versus data, and he noted that test cases can be uploaded and published on NIST’s site for reuse by others.


Owen informed the group that GSA had issued an order for LMI to stop work on the NDRG but that he still hopes the xmlCoP can issue a consensus draft for transmittal to the AIC’s Governance Subcommittee for further consideration. Ken Sall suggested that comments be sent to Owen, but Owen indicated he is not interested in receiving and does not have the capacity to deal with generalized comments or additional questions. Instead, he asked those who would like to contribute to offer specific wording changes, additions and deletions in the draft, so that the group can determine whether consensus exists on the changes. Owen expressed frustration that the consensus of the group has not been accurately reflected thus far.


Ken outlined the big issues as he sees them and suggested that the NDRG be scoped for manageable progress. KC suggested encoding the rules and making the encoding part of the NDRG itself. Judy Newton observed that drafting of version 3 of ISO 11179 is underway and that comments are welcome. Betty Harvey questioned the rationale for using CCTS for documentation, saying that doing so it confusing and that the examples used inconsistent with the rules themselves. Sol Safran raised the issue of rules (MUST statements) versus guidelines (SHOULD statements), and Paul Macias noted that the intent of the draft NDRG is to focus on schemas that cut across agencies. Sol responded that he thinks it is appropriate to focus on data exchanged among agencies. Tom Merkle expressed the view that the NDRG will help to drive the National Information Exchange Model (NIEM) forward.


With respect to Ken’s suggestion to compile an XML schema for the NDRG, Simon Frechette observed that doing so would be very much in accord with the way NIST would like to move forward. Ken noted there are roughly 10 NDRs in the world and that use of such a schema would facilitate analyses and comparison of them.


Ken’s presentation is available at http://xml.gov/presentations/saic/ndrg.htm and his notes from this meeting are copied below.


Stephen Bruxton of Mark Logic briefed the group on potentials for unlocking the value of content through the use of XML and XQuery. He noted he had formerly been with Oracle for 14 years and he suggested there re real differences between data and “content”. He said content applications can be enabled by XML and XQuery and he contrasted that approach with what other vendors commonly do, which is to combine a database with a full-text query engine. Instead, he argued that what is needed is XML, XQuery, and an XML content server. He said Mark Logic has extended XML Schema to include binary nodes, and he noted that in addition to providing for query, XQuery is also a full programming language – enabling the manipulation and display of data, as well as query/retrieval. Owen pointed out that one of the keynote speakers at the XML 2005 conference, a vice president of IBM for data management, had observed that relational databases are good for “static” data, i.e., data whose schema does not change much, if at all, or often.


Stephen’s presentation is available at http://xml.gov/presentations/marklogic/xquery.pdf


Those who registered their presence at this meeting were:


Owen Ambur, Co-Chair, xmlCoP

Jared Andrews, LMI

Bruce Cox, USPTO

Kathy Flitter, Navy

Simon Frechette, NIST

Betty Harvey, ECC, Inc.

Puja Goyal, NIST

Ed Kelly, DOJ/NIJ

Serm Kulvatunyou, NIST

Peter Lyster, NIH/SDIWG

Glen Mazza, DoD (EDS)

Tom Merkle, NIJ

KC Morris, NIST

Robby Moss, Mitretek Systems

Judith Newton, Ashton Consulting

Sol Safran, IRS

Kenneth Sall, SAIC

Susan Turnbull, GSA

Allyson Ugarte, XBRL


Those who identified themselves on the teleconference line included:


Paul Macias, LMI


Please convey any additions or corrections to Owen_Ambur@ios.doi.gov


The following are Ken Sall’s notes from this meeting:

 

In a nutshell, I think there was general consensus among those present that the NDRG should go forward. The minimal effort approach would be to simply stitch together what LMI has provided to date, add some front and back matter, and get it out there for wider review. This would mean *not* addressing many of the recent comments, esp. Sec. 4-7, for the first (wider) release.

 

Another approach (not necessarily mutex with the above) would be to develop a XML Schema to represent an individual rule with its prefix and number, some notion of its strength (RFC 2119), and optionally its justification, exceptions, objections, responses to objections, etc. There is a simple strawman in my slides. However, NIST has a more involved schema that they use in their Quality of Design (QOD) tool and validation system. The thought is to combine the 2 schemas to accomplish multiple goals.

 

So from the NIST perspective, you can run an agency XSD thru their QOD to determine which NDRG rules it breaks (an over simplification that KC can elaborate on ;-) She noted that many NDRG rules aren't currently testable.

 

From another perspective, we'd have the rules (and justification, exceptions, objection, etc.) in a machine processable format that would be considered the Golden Source. So any given agency can write an XSLT (and XSL-FO) to, for example:

 

- pull all rules and justifications but ignore the exceptions and objections

- pull only rules that have no objections

- pull all rules that are MUST or MUST NOT

- pull rules that have an objection from a a particular agency

- etc.

 

In this way, we could have one monolithic source from which each agency could pick and choose, according to its own mission needs. While this would not achieve government-wide interoperability, the assumption is that agencies that need to collaborate more closely will reach agreements about which of the full set of rules they will both comply with.

 

Thus, each agency can create a customized "view" of the Monolithic NDRG which subsets the rules it finds acceptable/necessary and even customizes the document appearance. Yet we all trace back to the same source.

 

This also means that if the Monolithic NDRG has a MUST rule, a given agency can reduce its strength to a SHOULD, if necessary. OTOH, if a agency wants to strength a SHOULD rule to a MUST, they are free to do so. If we are smart about how we ID the rules, we can even run "differences" between Agency A's and Agency B's NDRG, if desired. Each agency should be able to add new rules of its own to their NDRG, as well.

 

Major open issues include:

 

- Funding

- Governance

- Lead editor and active contributors (who actually write/edit)

- Schema writers

- and of course, Registry


To Ken’s list of open issues, in her follow-up note, KC Morris added: “who would own this database of rules?"