DRAFT Meeting Notes from the EM-TC Meeting

Draft Meeting Notes from the EDXL-RIM SC Telecon Meeting

Date: January 13, 2011, 12:00 PM EST

Attendance: Rex, Jeff, Werner

We have a quorum.

Note Taker: Jeff Waters

Note Taker’s Summary: At today's meeting, the members discussed the following topics:

1. What is the process by which the RIM handles and “approves” submissions for reusable EDXL schema components? (Answer: Essentially, the RIM blesses elements to use the common types (CT) namespace. The RIM will make submissions available in a folder and/or subversion to assist immediate potential reuse among subcommittees and then also review the submission, any potential conflicts, report back to subcommittees if any, otherwise make recommendation to EM TC that the component be added to the common types namespace. No more formal action is required. The formal inclusion of the components in a specification with public review occurs in the individual subcommittees which use the components. Periodically, RIM may gather together what has been added into the common types namespace and produce some formal document, e.g. a white paper, that describes what's there. But we need to visit with OASIS staff to determine whether this process complies with their formalities and uses of namespaces. Action Item: Jeff will follow up with Robin. )

2. Where do we keep the approved common types? (Answer: We have a folder in the RIM documents, but perhaps better to use a publicly available OASIS folder for final versions and also perhaps subversion repository to track interim versions. )

Background:The Reference Information Model (RIM) Subcommittee is concerned with documentation and reuse of emergency data components across all of the EDXL standards, including new EDXL standards that are emerging. Rather than make the same mistakes over again, the RIM is intended to develop products which can help provide guidance by encapsulating lessons learned and helping new standard subcommittees understand recurring issues and best practices for handling them. The RIM members have been revisiting how best to define and proceed with this vision and deliverables, based on the recent requests by subcommittees for reusable common types, including a CIQ common profile for easy-to-use elements for organizational information relevant for Emergency Management, as well as geo-oasis:Where profile for easy-to- use geographic information, and also for time/duration components. Werner recently submitted a draft vision and the members at today's meeting considered a lightweight process for allowing subcommittees to submit candidate common types, where the responsibility of the RIM is to keep a repository of common types, advise of potential conflicts, and make recommendations to EM TC to authorize the use of the common types namespace for the submitted components.

References: (1) Werner's draft vision: http://www.oasis-open.org/apps/org/workgroup/emergency- rim/email/archives/201012/doc00000.doc (2) Jeff's thoughts on a RIM process: RIM_PROCESS_DRAFT_SUGGESTION

Meeting Discussion:

Jeff: Was our last meeting December 16?

Rex: I'm looking, we canceled, so this is the last meeting on December 16.

Rex: We canonized the Common Types and Common Types candidate folders.

Jeff: Another key thing that Werner contributed was an answer to how do we get submissions and that the Adoption TC will pick up the gauntlet to assign people to each committee with this responsibility.

Rex: From DE and sitrep, we have more.

Werner: I identified 13 entities or so that need to be included.

Rex: We need to establish namespaces. But first we need to go through the interim TC administrator and we need to be careful to get it correct. We have the common types and the sitreps. And I think we need to work sitreps through messages and notifications subcommittee and common types through this committee.

------TOPIC 1: What is the process by which the RIM handles and “approves” submissions for reusable EDXL schema components? (Answer: Essentially, the RIM blesses elements to use the common types (CT) namespace. The RIM will make submissions available in a folder and/or subversion to assist immediate potential reuse among subcommittees and then also review the submission, any potential conflicts, report back to subcommittees if any, otherwise make recommendation to EM TC that the component be added to the common types namespace. No more formal action is required. The formal inclusion of the components in a specification with public review occurs in the individual subcommittees which use the components. Periodically, RIM may gather together what has been added into the common types namespace and produce some formal document, e.g. a white paper, that describes what's there. But we need to visit with OASIS staff to determine whether this process complies with their formalities and uses of namespaces. Action Item: Jeff will follow up with Robin. ) ------Jeff: I was wondering how submission is done, if an element in sitreps is identified for reuse, then how do we submit it as a contribution to the common types schema or as a contribution of its own schema.

Rex: The folders we've setup are there, but either of you is a better person to speak with Robin about namespaces. Because of your familiarity. I think we want to answer two questions: Is this something that we need to have in the official public repository? I think it is and has to go through the process, the regular approval process or what I think we want to do, if we possibly can, is we ask OASIS to bless our creation of a namespace operating from within the TC's document repository and we need a new folder. Candidate common types depending on single schema or bunch of little ones would be added to and released for public review and commented on and it takes some time. So we need to calibrate that to report back to messages and notifications and the DE subcommittees for how to reuse the common types. So what do we have to do to use the common types? It will be approved with rest of spec. The common types won't be pre-approved and it will be in some non-canonical place, it's something we have to tease apart and make sure we get correct.

Jeff: My suggestion is a two-tier process, whereby if there's submission, it can be visible and accessible and if it's useful, a subcommittee could grab it and start including it in its work, even though not formally approved on our side, and we do this for informal information sharing and then we go forward with our own process to get things blessed

Werner: The namespace still needs to be addressed. What we say to sitrep, use CT: and for them that's sufficient. They define CT with whatever URN.

Rex: The CT resolves to the candidate common types folder.

Werner: The candidate or the approved?

Rex: We don't have an approved yet.

Werner: That's what I'm concerned about, Jeff's statement about whether we are slowing down or not the process.

------TOPIC 2: Where do we keep the approved common types? (Answer: We have a folder in the RIM documents, but perhaps better to use a publicly available OASIS folder for final versions and also perhaps subversion repository to track interim versions. ) ------Rex: Can we also provide a namespace usable folder inside the technical subcommittee's documents or inside TC's documents that can be namespaced, the resolution of a publicly available namespace. So sitrep and DE can go through their approval process. I don't know if that's a good idea or not. We need to have a namespace and it needs to resolve.

Jeff: I visited with Robin, just to update you, there is a OASIS-hosted subversion we can use and Elysa will bring it up at the next TC.

Werner: But the public can't be relied on to have to get a client to use the subversion.

Jeff: Robin noted that Kavi is still the official repository.

Rex: I'm not sure that's a problem.

Werner: I'm just talking about how to get a grasp of the standard.

Rex: I don't think people grabbing down the data dictionary are going to care enough to use an API and worry about subversion.

Werner: We would use subversion for current ongoing work and Kavi for the formal final products that the public can easily access.

Rex: Does that address your concern?

Werner: We need a mechanism to handle versioning, but for the general public to access through these clients is too intimidating.

Jeff: There is html interface through tools.oasis-open.org which will help with ordinary users.

Werner: Is this site password protected?

Rex: I'm checking. Yes, it's open to the public.

Werner: Is this good or bad?

Rex: This introduces another task that we get to do.

Jeff: Everything really in Kavi as far as uploaded files is accessible to the public.

Rex: Yes, but it's hard to get there without a top-down browsing capability.

Werner: What are we going to use subversion for as opposed to folders? Rex: Subversion doesn't solve the namespace problem. It allows people to check things. We could give a false namespace that resolves to the subversion, but that would be a lot of bookkeeping.

Jeff: I think you might, if you buy into versioning, you might use it for everything and Kavi is for final products and things that don't need versioning, like maybe minutes, etc.

Rex: What about the namespace?

Jeff: If Oasis staff will let us use a namespace for interim products to assist with reusable information sharing, although the products are not approved yet except through individual subcommittees who use the products.

Rex: Once a standard has been approved, it has an official namespace different from what you used in a public review document. I don't like the idea that somebody creates an application on a namespace that gets changed.

Rex: Ask Robin how do we do this.

Jeff: I will.

Rex: We need to have a way for these common types, that will be used across specifications, then we need it and we ideally need it so the namespace doesn't change.

Jeff: Also fyi, I had to submit namespaces for us to use in our submission form, including the CT one.

Rex: Let's double-check it and then we'll inform the TC, the namespace should continue to work.

------TOPIC 1 (revisited): What is the process by which the RIM handles and “approves” submissions for reusable EDXL schema components? (See Answer above.) ------Werner: We should be clear about the process we will use.

Rex: That's the tricky one.

Werner: Let's shoot for a lightweight process. The code gets approved through the process of the sitrep and then if we want to integrate it into common types then we do that within the TC and we don't go to the public, cause the public thing is not the common types, it's the stirep code. Otherwise we will have a huge delay. Jeff: The common types never show up in their own official approved schema?

Werner: Yes.

Rex: If the namespace remains the same, then if a subcommittee approves it, then it can go into the common types and if it changes in course of being approved then nothing in the namespace changes. You don't have to worry about the approval process. The final approval of the common types, is an issue of whether we have one big common types or a bunch of individual ones. What Werner is saying is there is never a schema a long one or short one.

Rex: Here's my question, doesn't this mean we have to ask OASIS for a new subprocess in the TC process?

Werner: I wouldn't say ask for a new process. Let's explain the way we want to do it and get their blessing. What we're doing is we're taking a specification and identifying pieces that are common types and those pieces are in the code of the specification submitted for public approval and then once approved we integrate into common types.

Jeff: But that will break applications if the namespace changes.

Rex: I think you're onto something though Werner. I like not having a separate process for approval of common types, cause that's a lot of work. If we're putting it into one large one, that's easier to manage and if we aren't bothering with separate approvals.

Werner: If SITREP and RIM get together, then we decide certain components are worthy of common type, but that's the way we submit it...

Rex: I don't think we need a separate process in TC to make it a common type. If we do it this way, RIM has adequate time to look at them during public review. Like you said 13 types pulled from sitrep, but we should look at those next meeting and we should conduct our review and then as far as we can see, no reason to not include in common types, but no need to go through TC approval, if the elements are going through public review in other specs.

Rex: We report to the TC our recommendation and just regular motion to approve.

Werner: We want the other subcommittees to be aware of it.

Rex: For example, the common types are in the sitrep spec. So we can explain to TC that approval of this document in stirep means also that you are approving the common types cause it is in the TC approval process. Jeff: That works for elements that we identify as common types early on in the spec process.

Rex: So we review the sitrep ones for example at the next meeting and we approve it.

Jeff: So essentially what we're saying is that in the RIM, what we do is we bless elements to use the CT namespace.

Rex: Exactly.

Werner: Our work goes further, cause maybe there are similar elements from other standards. So this may change what we see as a common type. How do we deal with that?

Rex: We take it one at a time.

Jeff: We identify conflicts and then drop them back to subcommittees with perhaps some recommendations. We should perhaps include multiple versions of common types?

Werner: What do we do about conflicts?

Jeff: I suggest that we take submissions, like Vcard and Xpil, and we simply identify the conflict and then maybe our process is to accept both. This favors reuse of information and sharing and expands awareness and allows subcommittees to choose. If we do global elements, we could put in one schema, or we could have separate schemas.

Rex: We go to TC and ask Robin if we can have a sanctified namespace for common types and then we describe the process we have so far. We also consider using subversion and we already have the common types and candidate common types for people to start working with. And then we can explain as much as we can the process. We want to work with subcommittees while they are doing their work to identify common types and use DE and sitreps to practice this right now.

Jeff: Are we the police or are we just the sharers?

Werner: We should bear responsibility for consistency?

Jeff: If a conflict, then TC should decide but we would represent both.

Jeff: That's it for today. Thanks.

Meeting Adjourned.