Name (Handle)	Name (Handle)
Owen Ambur (OA)	Marion Royal (MR)
Rex Brooks (RB)	Ken Sall (KS)
Mark Crawford (MC)	Chris Traver (CT)
Serm Kulvatunyou (SK)	Susan Turnbull (ST)
Paul Macias (PM)	Todd Vincent (TV)
Tom Merkle (TM)	Rebecca Wilde (RW)
Vicky Niblett (VN)

MINUTES ORGANIZATION:

 

The conversational style of the minutes is intended to give those not in attendance a sense of the discussion and assist in helping attendees in recalling main points raised in the flow of discussion. However, attributed statements should not be interpreted as exact quotes. Nor should it be assumed that every comment made is presented.

 

The minutes are organized into major topic areas. The sections are:

 

1.   NDR Scope and Purpose

2.   Schema Modularity

3.   Namespaces

4.   Versioning

5.   Other Rule Discussions

 

Also, there are two attachments:

 

Attachment A: Language for Title, Scope, and Purpose

Attachment B: Action Items List

 

A portion of the meeting addressed specific comments previously submitted and tracked in a separate NDR comment tracking spreadsheet. Discussions and resolutions of those comments are captured on the tracking sheet with a leading date tag of “[8/11]”.

NDR Scope and Purpose

{This section highlights the discussion leading to development of the scope and purpose for the Federal NDR. The participants agreed that settling on this portion of the NDR is necessary in determining how to approach the remainder of the document.}

OA: “Canonical” is too strong a sentiment for the Federal NDR. The NDR purpose needs to focus on activities that encourage good design.

MC: Understand that there are concerns of “MUST” statements in the NDR. We should be aware in a discussion of “MUST” versus “SHOULD” that there are costs to be considered. It’s not that “SHOULD” is wrong to include, but we need to be aware of the costs it will have on developers of software and those reviewing XML for compliance.

KS: Tools can flag “SHOULD” occurrences.

MC: What should a reviewer do about a “SHOULD” statement? They are not enforceable.

TV: A governance model needs to be developed, but it will take longer than desired. So instead we should consider looking at canonical NDRs for each agency (as has been the trend), even though a single canonical document would be desirable. A single government-wide canonical document has been deemed impossible, so this document could be a guideline for those agencies developing their agency NDRs.

OA: If consensus can be reached on the Federal NDR, I would like to pass on the document to the governance sub-committee for consideration if there is to be policy.

MC: Lots of NDRs have been written since there was not a unified NDR to adopt. Efforts by EPA and the Department of Navy (DON)would have preferred to have had Federal guidance but were working in a vacuum. These groups’ NDRs were developed out of the UBL since that is what was available. I would like to see a canonical NDR even if it is limited to transaction data. For example, DON is interested in eliminating their NDR if there was a higher authority. Such adoption would be in keeping with the DON policy of accepting higher-level standards.

TV: Agree that “SHOULD” are difficult to program in automated systems.

MC: Need to determine what the end goal is. Is it to develop Federal wide standards?

TM: Is the DRM addressing governance?

ST: Governance is a separate activity. But will be important to develop in time as we learn more from groups such as this.

RB: Is the Federal NDR to be a model for other NDRs? Does it provide a means for mapping between implementations of different NDRs?

MC: A document of all “SHOULD” statements as a guide for agency NDR would be better than nothing at all.

TV: I’m more interested in software that can mange schemas according to the rules for code generators. If the NDR are limited to transactional data with “MUST” statements, that would create incentive for software development.

OA: I’m more interested on the human level of what the NDR can get people to do because it is the right thing.

TM: If there are “SHOULD” then the agency could choose to have their vendors support the NDR in their implementations.

MC: Any “SHOULD” is already supported.

TV: Most of the rules are supported. But, areas such as Version and Modularity are rules that refine the allowable activities not given in the standards.

KS: Is there any standard that has been agreed to across the government?

MC: Not in XML, but EDI is agreed to ASC X12.

KS: We don’t have the ability to represent the entire government.

MC: Most decisions are not Government-wide discussions because they never reach consensus.

OA: Agreed, but some decisions are bad decisions because of that.

KS: If limited to transactional it is ok, because that is where these rules originated.

MC: Do not see an issue for document oriented schemas as they do not have the same requirements because document oriented schemas are geared for display purposes.

KS: That is not the case in the IC community. The IC community has needs for designating clearances.

MC: The point is that document schema don’t have the contractual legal requirements that accompany transactional schemas.

OA: I believe that there are items where he would want to apply some rules to publications.

MC: I’d prefer document oriented rules go further than transactional rules to allow mixed content in downstream activities.

TV: Part of refining the NDR is supported by testing as you go along and see how the rules hang together. If there were more examples to show they work, it would be easier to evaluate the proposed rules.

OA: DRM will be meeting with NIST and others to discuss the testing of DRM. We need to look at what it means if the DRM schema doesn’t conform to the NDRs. If the data exchange elements don’t conform, what does that say?

MC: The DRM effort is not trying to conform to NDR at this time.

KS: There are some areas that have attempted to conform. However, it is not the priority to conform to NDR. Also the DRM and NDR are both moving targets, that doesn’t make it feasible. That doesn’t mean the schema can’t be retrofitted to a set of NDRs at some point.

MR: I’d like to know who people are representing in order to understand what NDRs have been looked at. Todd mentioned he’s worked with some NDR.

TV: Our NDRs are referred to as a Schema Framework. The have been used with various clients including judicial clients in California.

MR: When this NDR project started the approach looked at developing a canonical NDR to facilitate discussions between agencies. We can resolve a lot of these comments and look at transactional vs. others. Welcome all comments from parties that will help improve the document to make it better.

OA: I’m more comfortable if this NDR is a recommendation.

MR: The NDR is definitely not mandate, but I would like it to be a basis for policy.

KS: Is there agreement with LMI on that point.

MC: I am the first to admit that I am an idealist and try to advise on the best possible outcome for the Federal government. But I also recognize that part of consensus building is to be practical when decisions need to be made.

KS: What are the priorities? What is the biggest priority?

MR: To put something in the hands of developers that they could use today as a common reference. The NDR can assist developers with producing XML that can be consistent, reliable, and be interoperable beyond their immediate consideration. I would also like to have a way of mapping between different rules.

OA: Another goal is to develop a means for encouraging software support.

MR: We should be able to get started with a document that reflects knowledge of today. We can come back later with more information as more is learned and justify some to be “MUST” statements.

KS: This type of explanation is what we have been looking for on the listserve posts.

MR: Then lets do it.

{At this point the group began to review specific language for changing the document’s title and scope. See Attachment A for the resulting language.}

OA: Can we agree this is a guiding statement?

TV: Yes, but there is another statement further down relating to tying funding to conformance. Recommend that a statement be developed addressing the tying of funding to conformance.

OA: I believe we would want to encourage people to use the NDR as a reference to their XML activities.

TV: Beware of possible consequences if there are problems with conforming.

MR: Agencies would probably use the NDR as a reference to be looked at for recommendations.

{At this point the group began to review proposed bullets describing desired outcomes as part of a document purpose. See Attachment A for the resulting language.}

Bullet 1 – Canonical schemas

TM: Suggest leaving a placeholder for “Federal canonical schemas” that are the ones developed beyond the base datatype schemas.

{Removed as not necessary}

Bullet 2 – Flexible Federal modularity model

{No comments}

Bullet 3 – Clearly defined namespaces

TV: Agree there needs to be guidance on namespaces

Bullet 4 – Versioning scheme

TV: Need consistency.

OA: Can say it without saying “all” federal and agency schema. And make “government schema”

Bullet 5 – Canonical datatypes schema

MC: This refers to the schema for common datatypes. The role of this schema will be explained later in discussions on modularity.

TV: Does not agree, but willing to move on.

Bullet 6 – Agency Specific NDRs that build on the Federal NDRs

OA: Don’t limit to line of business (e.g. initiatives)

MC: Will initiatives develop their own NDR?

TV: Allow for acceptance of external NDRs.

OA: Do not want to encourage stove-piping. This can be open to communities of practice.

Bullet 7 – Map NDRs to core specification

MR: I’d like to see a reference to map different NDRs to each other.

Bullet 8 – Consistent, reusable XML components

            Schema, Schema Modules, Simple and Complex Types, Elements, Attributes

MC: I wanted to include reference to a registry

OW: Insert “…that may be stored…”

KS: I want to know where to find these when they eventually exist.

MC: How about “available for reuse” to avoid any specific storage mechanism

TM: What about “tool sets”?

MC: Tool sets should be added as another bullet

KS: Use “such as …” to clarify schema modules

Bullet 9 – Set of tools to facilitate development, validation, and interoperability

{No comments}

 

Schema Modularity

{This section reflects discussion on schema modularity. The discussion relates to material presented in Section 3.6 of Draft NDR. Mark Crawford started the discussion by reviewing Figure 3-1.}

MC: The figure has a root schema module that is the main schema for conducting a specific business activity. The root schema is assembled by importing the other components of the figure.

MC: Internal schema modules are structures that are specific to the given namespace. While an internal schema could be reused by others of that namespace, it is an internal definition because it has been determined that it is not effective to add its structures to the overall reusable components.

MC: External reusable standards could be imported.

KS: Are there problems with external standards that don’t follow the same design rules?

MC: No, namespaces will be different, and will avoiding collision. The only problem would be situations like UBL requiring conformance. But CEFACT agrees that situation is not right and should be a “SHOULD”.

TV: Maybe put a message of caution where imported schemas may not adhere to the same set of schema rules. The rules need to allow for an unambiguous identification that something has been imported that will not necessarily conform (so don’t expect to pass automated checks.)

MC: The lower part of the diagram is intended to show the importation of Federal and Agency modules. These will obviously change with today’s purpose/scope changes.

TV: Believe there are three models that should be addressed in the NDR. Let me preface that I liked the DON NDR, but saw points in the details that could be better. In describing the models there are “information objects” that represent common things (e.g. person, address, organization). The three models are:

1) one schema, multiple objects (e.g. Global Justice)

2) multiple schema, multiple objects (e.g. current draft NDR)

3) one schema, one object, one namespace (e.g. person.xsd)

TV: Believe the third approach is more efficient and more flexibility compared to a one schema module. The validation time can take a few minutes in the one schema approach. I want to test the second model.

MC: Test using the UBL specs that can be download from OASIS. May not realize this, but the original concept for ebXML was similar to the third model that registered specific objects that could be pulled dynamically. A profile could be registered to identify the relevant objects available for a particular organization and a trading partner could identify and build transactions dynamically.

TV: Largest our implementations has seen is 24 information objects for a complete format, with an average of 12-13 objects per format. There is some overhead from pulling those things together, but they are much easier to reuse. You save space, because you only import the objects you need.

MC: An approach being developed for implementers of the second model is to create flatten schemas of the common reusable components to save on the overhead of importing. Specifically, making subsets of the reusable components for a particular business area. Can also flatten further to have common reusables specific objects that are necessary for a specific schema.

TV: When you break up the reusable components schema you have the choice of using the same namespace or create a different namespace. The second option is nothing more than a way of doing the third model.

MC: The approach being developed uses the same namespace. Since there is no issue with collision, we don’t need a new namespace.

TV: But if the namespace doesn’t change there is an issue on the instance document because multiple breakdowns would use the same namespace. If you do the third model there is no ambiguity as to what schema to use to verify the instance associated with a namespace. Also issue of versioning is managed by changing with each object.

MC: Disagree, because namespaces are not the same as schema location.

TV: But what about interoperability? Assume 10 objects out of 100 reusable objects are put into a new sub-schema. If you add an additional object you cannot tell the difference.

MC: There should not be a conflict. The owner of the namespace would be adding them to the full namespace. Additions from non-namespace owner would be for a new namespace.

TV: I do not intend to convince group, but show that there is an option in practice that is working. We can compare as options that are working, or compare one as better than another. I encourage people to test for themselves.

MC: If we had a cross-government registry that is a fully functional ebXML registry then would support a combination of model 2 & 3. Don’t know if we’ll get there.

MR: Todd, how are you assembling your schemas?

TV: We started out as manually constructed, but have evolved to tools to assist in construction.

MC: That’s an issue on how to manage without a registry/repository.

TV: Agreed that the third model needs a registry. We use a directory system on the servers. There are three repositories for normative schemas. We provide clients with the rules to replicate on their local servers.

MC: Based on some objects in some government data transactions we could see the some transactions with over a hundred objects. Across the government conceptual data components are going to number into the thousands. And the related business specific context components will be significantly more. Can the performance be managed at that level in the third model?

TV: Need to manage the same number of objects anyways. From top down it looks daunting. But bottom-up is simpler. Groups would look to develop specific objects just for their own needs.

MR: What if like organizations build similar forms using the third model? That could affect interoperability.

TV: Uniform codes are the basis for states to develop their rules and are commonly tweaked about 2-5% for their needs. If we can’t have one standard for all the states, then wouldn’t it be nice to have a template that they would tweak only 5%. If the naming and design rules are similar then the only differences would be a few pieces of data. Not what we’d want in an ideal world, but the practical approach is to accept that there will be a small number of issues. The approach supported by NDRs will take organizations the majority of the way towards compatibility.

MR: Not convinced that the third module is the approach without a registry.

TV: Need a registry/repository of some sort for dissemination of information.

MC: The difference is going to be the degree of services from the registry.

MC: I’ve written three namespaces that could be developed for the concept of “address” under the third model approach.

urn:us:gov:fed:gsa:schema:address:1.0

urn:us:gov:fed:omb:schema:address:1.0

urn:us:gov:state:va:schema:address:1.0

These “addresses” could be exactly the same and people could pick from any of the available objects that meet the trading partner need.

TV: Yes, they can see all the model addresses to develop their own address without having to ask permission of a committee to change an object developed for another’s needs. I would like to allow these models into the NDR and make some recommendations.

MR: Could you draft some text for the NDR to be considered?

{Action Item: Todd will develop content for consideration into the NDR. Will provide repost of links to further information.}

MC: Believe first model is closer to the second model than it appears. It is mostly an aspect that Global Justice only has reusable components relevant to Global Justice.

MR: Third model allows for extensibility.

MC: And the third model is more difficult for management.

 

Namespaces:

{The following represents the main points of a discussion on the types and functions of namespaces.}

TV: There are a couple issues here. 1) URI v URN, and 2) parse-ability of namespaces. Believe parse-ability is not dependent on URI v URN.

MR: The NDR has gone with URN to avoid the assumption that the schema will be found at the location of a URL.

MC: A URL is not required to be permanent. A URN is to be permanent.

TV: Can be a rule that if you specify a URI in a schema then the resource must be permanent. Restricting the changeability of URLs is an option.

KS: What about when an organization changes names?

TV: These are just strings that can be permanent by rule and maintain resolvability. Whereas there isn’t registration and resolvability of URN.

MR: There is a proposal to register URNs since they are of the .gov domain. This has expanded to state governments.

TV: Do not believe the current proposal for URN is parse-able. In our approach the namespace parses as 1) Domain, 2) “schema”, 3) generic, and 4) version (optional). Generic is an object name followed by variable string divided by slashes defining the logical area. Believe a variable part is needed to add flexibility in clarifying the name.

MC: The issue is that your approach is using the namespace as the schema location.

TV: Yes, by rule. That ensures that relative paths will always work.

MC: There’s a difficulty normalizing the naming of schema locations.

TV: Don’t need to for the root.

MC: What about collision?

TV: Avoided by rule.

MC: Prefer to use namespaces for namespace sake, and not locations.

KS: Problems with the IC community because conceptually one works from a common schema, but once it’s placed on a secured network the locations have to change.

MC: UBL separated namespaces from locations because there could be different locations.

TV: Believe there are things from URLs that you don’t get from URNs.

MR: Other comment was trying to put specific URNs.

MC: This is confusing schema locations from namespaces.

TV: They are different, but they can be combined. A big reason was so that a person getting an instance document could find the schema.

MR: An opposite argument can be made that a URL can’t always be resolved, while a URN will always be that location.

MC: Problem is that there are Federal agencies using a single namespace for all there schemas.

TV: Believe that the practice of reusing the same namespace causes problems and is sloppy.

MR: Believe it is the opposite in that having the namespace and location separated causes people to think more clearly about each.

TV: Requiring them be linked by rule enforces namespaces and location to resolve together.

RW: The Air Force is currently putting our schemas up on a specific path. If the partner wants to move it to there own locations they will not match.

TV: The process throws away the root schema domain. As long as you throw it away you can exchange them by rule. Under the convention we know that “schema” is the demarcation to throw away the first part.

MR: But that can be done with schema location.

TV: Yes, but assume the location doesn’t change between versions, there will be a failure to resolve.

MR: Problem exists in either.

TV: But if they strongly tie to names as a rule then versions are managed.

OA: Concern that we are going to be arguing this forever. Believe that the handle registry would resolve the issue of URN and URIs.

MR: How about if agencies use URL for namespace then we give them one set of guidance, and alternative guidance for using URNs.

MC: Might be collision, but that in theory should not be an issue.

MR: Recommend the URN and provide consistent approach to either namespace approach.

MC: Add states to .gov?

MR: Need to distinguish state and local governments from Federal. The URN proposed here can be parsed out to the government domain. Need Todd to provide examples of the domains under the URL for states.

TV: It will be done.

RW: What about sub-domains?

MC: May need an additional level between 4 & 5.

TV: Need another separator for parsing variable sub-domains.

MC: Saw this in UBL to avoid intimating another level. Could use a hyphen (-).

TV: Recommend avoiding using a period since it is commonly used for programming purposes.

MC: We’ll need to look at the programmatic recommendations on characters.

 

Versioning

{This section represents the discussion on versioning of schema modules. Discussion began looking at the rules presented in Section 3.5.}

KS: What is the “document-id”?

MC: It is the formal name of the document. Need to clean up the explanation.

MC: Do we agree on rule VER4?

ALL: Yes.

KS: What about skipping numbers for rules VER6 and VER7?

MR: That is covered. Sequentially ordered, but not necessarily incremented.

TM: Probably should have an example of that skipping numbers.

ST: Believe the DRM is using a W3C guidance on versioning. Will provide to Mark information on the W3C guidance.

TV: From experience if you are not keeping up with the W3C standards you are not aware of changes to their recommendations, and you loose access to the old version.

MC: A big issue is that versions have to stay available as some will not upgrade with changes. Need a persistent location.

TV: Agree and support documentation should also be persistent.

MC: The vision is that registry will hold all that information until someone decides to deprecate it.

OA: See handles as a way to get to the location where content is at regardless of approach.

TV: Reason we tie naming rules and locations, we can view from the instance.

OA: Do we agree?

MR: We can do the same with schema location.

MC: On the area of major/minor versions should we dictate a standard for what is “minor” for the Federal community to help developers, and make it guidance to agencies and states to follow the same.

TV: Should base what is “minor” on the impacted size of the community effected.

MC: Believe the definition of what is “minor” should be based on the technical impact not the number effected.

TV: Cannot anticipate what people will do with your schema. Even a “minor” change could have a significant change to a number of people.

MC: The point is that a “minor” change would be one that does not impact people from continuing to use the previous minor versions. Compared to a “major” change that means instance validations will not work unless you update.

TV: Even minor changes have an impact because the namespace has been effected.

MC: They are not effected if the namespace is decoupled from the version.

TV: Even if they are not tied the understanding of people to resolve what is minor from within the same namespace has an impact.

MC: If you tightly control what the minor changes are the impact can be controlled to determine when an new namespace must be created.

Other Rule Discussions

{The following captured discussions on explaining rules from UBL}

OA: If we make something “MUST” we need to make sufficient justifications.

MC: A lot of the material can be imported from UBL and the discussions.

KS: Those explanations need to be in the document for context.

MR: When UBL developed their rules, proposals required a white paper justification for debate.

KS: One example of a concept needing explanation comes from UBL’s use of libraries. UBL is built on the assumption that there is a library.

MR: DRM is going to be the library of components that we can reference. If Mark had it his way there would be a registry/repository.

TM: NIEM is being primed by Global Justice – Could there be other registries?

MC: There likely will be a registry with components open to everyone.

KS: But what of adopted objects from UBL? Take example concepts like “party”.

MC: UBL is a conceptual model. They are not instantiations in themselves, but are to be used in developing the library in UN/CEFACT.

KS: Where do we get that library.

MC: As soon as it is developed it will be posted on Core.gov and announced to the list and other groups.

MR: Even if we don’t have the core library, building off XML from those library constructs can be cut and pasted into XML for reuse. Changes would be handled by versioning.

KS: What about extension and restriction? Restrictions are pretty straight forward, but what are the rules for extending?

MC: Depends. Are XML tied to models that have rigid extension and restriction rules? If not then managing extension and restriction becomes hard to manage.

KS: Can we come up with concrete examples with how we are going to address items that every agency is going to need (i.e. “person”)? Is every attribute reflected for the concept?

MR: That is not the focus of this document. Those are message assembly questions.

KS: I’m talking about usability.

MR: The CEFACT way is to restrict the model or propose changes to the model.

MC: UBL does a similar approach. Either change the model, or develop custom extensions that operate outside UBL.

OA: If person does not meet your need, then you need to create a second “person” object?

MR: You need to purpose the properties that make it different.

MC: There is a harmonization effort that checks that proposed structures do not duplicate existing structures.

MR: Another 11179 concept that applies is associations, where you have one object related to another. You can extend an object class by linking it to another object class.

KS: But we’ve pulled CCTS.

MC: But all the concepts are in the NDR using 11179 phrases instead of CCTS phrases.

MR: And things will evolve when we have the DRM. But what will change will not be the rules. What will change is the non-normative discussions.

MC: There is a message from Mike DeConta that says DRM is focusing on identification not the data.

MC: Does the scope change given the purpose?

OA: Reformulate to address improvement to all branches of government and include state and local governments.

 

Attachment A: Language for Title, Scope, and Purpose

TITLE: Federal XML Naming and Design Rules and Guidelines

 

SCOPE:

This Federal XML Naming and Design Rules and Guidelines document is applicable to intended for use by all Executive Branch Departments and Agencies (hereinafter referred to as Agency) that employ use XML, including all commercial and government off-the-shelf XML related product implementations. It is applicable to should be used by all contractors and vendors doing XML development work on behalf of Departments and Agencies. Agencies developing specific XML Naming and Design Rules and Guidelines should use this document as the baseline for those efforts.

 

PURPOSE:

The purpose of this document is to provide a set of rules and guidelines that will enable development of:

 

¿ a flexible federal modularity model that defines the structure for creating interoperable schema and schema modules

¿ a clearly defined namespace scheme that ensures consistency across Agencies

¿ a versioning scheme that will support consistency in versioning of government schema

¿ a Federal canonical schema for base datatypes (disagreement by Todd)

¿ specific NDR’s by government agencies or communities of practice that build on this document

¿ a reference to use for a mapping of different agency NDR’s to each other

¿ consistent, reusable XML components that may be made available for reuse such as:

o Schema

o Schema Modules such as reusable code lists and identifier lists

o Simple and Complex Types

o Elements

o Attributes

¿ a set of tools to facilitate ease of development, validation, and interoperability

 

Attachment B: Action Items List