OASIS Emergency Management TC

Expand all | Collapse all

Call for quorum - Thurs 11/2 4:45PM EST

  • 1.  Call for quorum - Thurs 11/2 4:45PM EST

    Posted 11-01-2006 11:18
    
    Dear EM-TC Members,

    We did not have a quorum for our meeting yesterday and we would like to get the HAVE moved forward to public comment, as well as review/approve the meeting notes for the past few meetings.  We had our meeting which is summarized in the notes that will be uploaded for review but without a quorum, we were not able to do any business.  We will plan to have a short meeting on Thursday just before the Msg/Not meeting on Resource Thursday evening at 4:45PM EST.  The EM-TC part of the meeting should only last 15 minutes if everyone can be prepared to vote on HAVE.  If you have any issues on the draft as it is posted or corrections to the meeting notes for the Sept and Oct meetings, please post them to the list as soon as possible. 

    Thanks! 
    Elysa Jones, Chair
    OASIS EM-TC
    Engineering Program Manager
    Warning Systems, Inc.

    PS - The EIC meeting will be today Nov 1.  You can dial in to 800-320-4330 pin # 327547


  • 2.  HAVE draft comment posted

    Posted 11-01-2006 19:57
      |   view attached

    Attachment(s)

    pdf
    NIEM_NDR-0.3.pdf   322 KB 1 version


  • 3.  Re: [emergency] HAVE draft comment posted

    Posted 11-02-2006 13:57
    Hi Tim,
    
    I posed my initial response earlier, but I wanted 
    to specifically address where in the process this 
    should be taken up wrt HAVE.
    
    My own feeling (subjective) is that it should be 
    held back until a subsequent version, e.g. v1.1. 
    or 2.0 because I suspect it will meet the 
    criterion that a substantive change requiring a 
    new 60-day public review has a threshold or 
    trigger whereby a substantive change is one that 
    "breaks" existing applications.
    
    Objectively, we literally can't afford to hold 
    this up, or vendors will produce their own 
    menagerie of proprietary solutions. This is what 
    happened for the OASIS SOA Reference Model TC 
    (and current Reference Architecture SC). It has 
    endured and continues to face the proliferation 
    of ESBs and "SOA Fabrics"  jockeying for the 
    inside track in the marketplace while we 
    carefully crafted the Reference Model and 
    continue to work on the Reference Architecture. 
    However, because both the model and architecture 
    are largely abstract, much like we can make the 
    NDR we can, I believe, absorb ESBs and Fabrics, 
    albeit with a very flexible shoe horn.
    
    So while the comparison is not precise, the 
    effect that ESB vendors have been running away 
    with the marketplace still applies.
    
    So we will have to attempt to incorporate NDR, 
    crafting it as a non-breaking, non normative 
    "best practice" in an appendix during and 
    immediately after the 60-day review IF we have 
    the time--which is to say, IF we are not swamped 
    with industry comments. We will also need to 
    include the advice that we expect to incorporate 
    a general-purpose NDR methodology in the next 
    version of HAVE and EDXL_DE along with all 
    subsequent members of the EDXL family.
    
    We may be able to do this because what we are 
    doing is establishing a methodology for NDR, not 
    a controlled vocabulary in itself. If NIEM is 
    looking for a the greater restriction of its own 
    controlled vocabulary, which is what we feared 
    early on in Mike Daconta's initial statements, we 
    would have a greater challenge, and I would have 
    to take the position that we are required to 
    ensure international applicability over any 
    specific national systems.
    
    Either way, its a tough pill that it is better to 
    take now than postpone because it is not going to 
    taste any better, and likely to ferment into much 
    worse, if we wait.
    
    Cheers,
    Rex
    
    At 2:57 PM -0500 11/1/06, Tim Grapes wrote:
    >All,
    >
    >I and others on and off the OASIS EM-TC would 
    >like to post a recommendation that the National 
    >Information Exchange Model (NIEM) Naming and 
    >Design Rules (NDR) be adopted and applied to the 
    >HAVE committee draft.  My understanding is that, 
    >although a consistent convention was used to 
    >name the elements, no formal NDR has been 
    >followed for HAVE or for Resource Messaging (RM).
    >
    >Please note that not adopting the NDR does not 
    >prevent use of NIEM to develop exchanges using 
    >EDXL standards; however, the difficulty for 
    >practitioners may be increased otherwise.  I 
    >realize that this feels Federal 
    >government-driven, but I don't see a down-side 
    >since the particular semantics applied should 
    >not negatively impact the International 
    >community. 
    >
    >Benefits:
    >·         Use HAVE as the starting point to 
    >begin applying a published and consistent naming 
    >convention across the EDXL standards
    >·         Promote reuse and facilitate simpler 
    >and more seamless use of NIEM for the 
    >development of IEPD's and implementation of 
    >exchanges using the EDXL standards.
    >·         Provide a straight-forward avenue and 
    >mechanism for state and local organizations to 
    >comply with grants language which specifies NIEM 
    >and EDXL
    >
    >We do not feel that the specification should be 
    >held up; HAVE should proceed into the 60-day 
    >comment period with this and other comments that 
    >have been posted.  If adopted by the TC, 
    >recommend that the NIEM NDR be adopted for the 
    >draft Resource Messaging and subsequent 
    >standards, and possibly to the Distribution 
    >Element when a successive version is put forth.
    >
    >I welcome any comments or feedback.  I will be 
    >on the call Thursday at 4:45.  Because HAVE is 
    >pending committee vote, I don't know where this 
    >comment should be formally posted.  Please 
    >advise and I will ensure that gets done.
    >
    >Sincerely,
    >Tim Grapes
    >Evolution Technologies, Inc.
    >Office:  (703) 654-6075
    >Mobile:  (703) 304-4829
    >


  • 4.  RE: [emergency] HAVE draft comment posted

    Posted 11-02-2006 14:03
    Rex,
    
    If we waited until the next version to adopt the NDR wouldn't that put us in
    the position of having an immediate major release (v2.0) since I doubt that
    it would be backwards compatible from the initial release?
    
    Thanks,
    Lee
    'We the unwilling, led by the unknowing have been doing the difficult with
    little for so long that we are now ready to tackle the impossible with
    nothing.' -- Local Fire communications reserve volunteer motto
    
    


  • 5.  RE: [emergency] HAVE draft comment posted

    Posted 11-02-2006 14:17
    Hey Rex,
    
    I do understand where you are coming from, but my feeling is that now is the
    time to adopt the NDR, before we have a release.  The NDR is conformant to
    ISO 11179, and I don't think it would be considered a substantive change -
    the structure and definitions are the same.  We would only be changing the
    semantics.  It should not break existing applications since HAVE is only a
    draft, and should only be used to this point for pilots and demos.  
    
    I do believe the time is now to incorporate this, but perhaps I don't fully
    understand the argument you put forth. As it stands, the TC has incorporated
    naming logic not based upon an NDR.  We're simply recommending adoption of a
    specific convention that will cure a lot of headaches down the pike.
    
    Thanks,
    
    Tim
    
    
    


  • 6.  RE: [emergency] HAVE draft comment posted

    Posted 11-02-2006 15:06
    All, 
    
    I am not against the NIEM NDR, but the TC should conduct the due
    diligence to understand if there are other alternatives or
    recommendations from OASIS. I do not want to be stuck in a position
    where we adopt this now, and OASIS then stipulates another NDR... 
    
    This will be a substantive change as it not just a change in the
    semantics but it involves a lot more effort - you need to align to the
    schema design rules, data modeling rules etc. Which brings me to my next
    question - what stage is this document in? The reason I ask is that I do
    not see any content in Sec 11, 12 etc. 
    
    I agree with the notion that we need to adopt a NDR and apply it
    consistently for all products, but we need to make sure that what we
    conduct the due diligence. 
    
    Sukumar
    
    
    
    


  • 7.  RE: [emergency] HAVE draft comment posted

    Posted 11-02-2006 15:11
    Sukumar,
    
    I agree.  We need to have an open discussion on this as soon as we can.
    Adopting a NDR is critical, but your point is well made - it may not be the
    NIEM NDR that is final - this will make NIEM work a lot harder - but I
    cannot imagine that every standards body that will be represented in NIEM
    will adopt their NDR....NIEM needs to address this from their side.  
    
    Thanks,
    Lee
    'We the unwilling, led by the unknowing have been doing the difficult with
    little for so long that we are now ready to tackle the impossible with
    nothing.' -- Local Fire communications reserve volunteer motto
    
    


  • 8.  RE: [emergency] HAVE draft comment posted

    Posted 11-02-2006 15:30
    Yes, Lee,
    
    I understand that, but I suspect it would take less time to do it that way...
    
    It's a question of one versus two 60-day public review periods. If we 
    have a 60-day pr now, we will need to have another if we add the NDR 
    to HAVE after the pr now. That means it will be at least six to eight 
    months in all probability before HAVE gets approved OASIS-wide. If we 
    do 1.1 in six months or eight months that is not out of line with 
    what we have seen in other circumstances,but tin the meantime we have 
    a functional HAVE. However, I have a suggestion to avoid that, too.
    
    This is not going to be an easy or rubber stamp effort, I'm afraid. 
    That's why I think the best option is to create an EDXL Reference 
    Information Model (EDXL_RIM) that includes a methodology for NDR with 
    which recast, but backward compatible applications of existing 
    specifications could be built. That way what an implementer does is 
    to create translation table from existing terms and definitions to 
    the RIM NDR, and then just reference the namespace of the translation 
    table in the application. Legacy apps work as is, or get translated. 
    The translation fit sthe NDR and are interoperable with sucessive 
    versions of the specs.
    
    I prefer that rather than re-engineering the specifications 
    themselves. My reply to Tim was trying to address the immediate 
    problems in a way that fits with what most people are familiar with 
    doing, but my strongest advice is to do the RIM rather than fussing 
    with individual specifications at this time. I believe we are going 
    to end up having to do both anyway, so I'm not especially inclined to 
    argue over it.
    
    I will however, insist on doing the due diligence to create the specs 
    correctly, regardless, and that means we are going to have the 
    discussion over how to shape the NDR for fitting international as 
    well national needs. THAT's the discussion I would prefer to postpone 
    until a later time, after we decide how we are going to deal with the 
    work in front of us.
    
    Cheers,
    Rex
    
    At 9:01 AM -0500 11/2/06, Lee Tincher wrote:
    >Rex,
    >
    >If we waited until the next version to adopt the NDR wouldn't that put us in
    >the position of having an immediate major release (v2.0) since I doubt that
    >it would be backwards compatible from the initial release?
    >
    >Thanks,
    >Lee
    >'We the unwilling, led by the unknowing have been doing the difficult with
    >little for so long that we are now ready to tackle the impossible with
    >nothing.' -- Local Fire communications reserve volunteer motto
    >
    >


  • 9.  RE: [emergency] HAVE draft comment posted

    Posted 11-02-2006 19:09
    Hi everyone,
    
      I just wanted to add a point of clarification. If substantive changes are made
    after an initial 60-day public review, the specification must be submitted for
    an additional public review that must lest at least 15 days. So, unless the
    changes are so extensive that the TC feels it is impossible to identify the
    changes and restrict comments to that area, the 2nd review could be for as few
    as 15 days.
    
    The bigger question is - if you're planning on making the change, it seems
    dishonest to ask people to spend time reviewing when you know it will be changed
    rather than waiting.
    
    Regards,
    
    Mary 
    
    > 


  • 10.  RE: [emergency] HAVE draft comment posted

    Posted 11-02-2006 19:38
    Hi Mary,
    
    I am happy to be corrected here, but it was my understanding that a 
    substantive change required a second full public review. I'm fairly 
    sure that this would more than qualify for a substantive change since 
    it would in some cases literally change the name of elements and 
    attributes. I agree that it would be unfair to ask people to spend 
    time reviewing, and, presumably, testing when we think a major change 
    is likely. The problem, in my opinion, is that we are not going to be 
    able to do the due diligence in this case in a week or two, or even 
    just a month, when I look at the amount of time other committees and 
    work groups have put in on the issues in NDR, when what we have is 
    fit to use now. If I could in good conscience give my blessing to 
    NIEM, it would be fine, but I need a lot more information and time to 
    study it before I can say that, and I think, in the end, we would 
    have to opt for a more international standard.
    
    You could join the conversation at 4:45 p.m. this afternoon if you'd 
    like to weigh in. We were hoping to only spend 15 minutes on it and 
    approve moving forward with HAVE but I think it is now unlikely that 
    we wil be able to do that.
    
    Cheers,
    Rex
    
    At 8:08 PM +0100 11/2/06, Mary McRae wrote:
    >Hi everyone,
    >
    >   I just wanted to add a point of clarification. If substantive 
    >changes are made
    >after an initial 60-day public review, the specification must be submitted for
    >an additional public review that must lest at least 15 days. So, unless the
    >changes are so extensive that the TC feels it is impossible to identify the
    >changes and restrict comments to that area, the 2nd review could be for as few
    >as 15 days.
    >
    >The bigger question is - if you're planning on making the change, it seems
    >dishonest to ask people to spend time reviewing when you know it 
    >will be changed
    >rather than waiting.
    >
    >Regards,
    >
    >Mary
    >
    >>  


  • 11.  RE: [emergency] HAVE draft comment posted

    Posted 11-02-2006 20:13
    Hi Rex,
    
      I'm in Germany - just arrived this morning - and am afraid I will be sound
    asleep by the time the meeting happens.
    
      I'll make your day :-) After an initial 60-day public review, the TC may make
    non-substantive (i.e. editorial) changes without requiring further review. If
    the TC makes substantive changes (and the TC decides whether or not such changes
    are substantive) than they must submit for a minimum 15-day public review. The
    additional burden is that the new public review draft must contain a complete
    change log, and preferably, a change-marked version, since only those changes
    made since the previous review are subject to comment.
    
      In general, I agree that this is a large issue - Elysa may want to speak with
    Jon Bosak (UBL chair) about the OASIS UBL NDR v1.0, although I think Sylvia has
    spoken well of the challenges. 
    
    Regards,
    
    Mary
    
    > 


  • 12.  RE: [emergency] HAVE draft comment posted

    Posted 11-02-2006 16:38
    Hi Rex,
    
    Although I haven't been able to be active in the TC, I continue to try to
    keep up with it's work. This particular topic is one that I cannot keep
    silent on since software that supports ISO 11179 and it's practical
    implementation, ISO 15000-5 are what my company creates software to for and
    where I spend most of my time in the standards arena.
    
    Adding any NDR that supports ISO 11179 will not be a minor task. It isn't
    something that can be done in a few months. Even with specialized tool
    support it will take a dedicated team many hours of pains taking work.
    Specifically adding the NIEM NDR may also produce a national solution
    instead of a international solution.
    
    I believe that there is an approach that will support multiple NDR including
    the NIEM and support the needs of the international community. Essentially,
    it is proceeding with the RIM work that I believe you have already started
    and incorporating ISO 15000-5 which includes support for ISO 11179-4. 
    
    Simply adding the NIEM NDR will not achieve support for the wide variety of
    requirements that the OASIS community will need. The NIEM NDR is a schema
    representation of a data model. In order to support the needs of an
    international community, you need a syntax neutral representation of the NDR
    first. ISO 15000-5 is a syntax neutral representation of 11179.
    Additionally, when the GJXDM was in development, many of the data
    requirements were submitted to UN/CEFACT and subsequently to ISO for
    inclusion in the current version of 15000-5. From the syntax neutral
    representation, you can have any number of NDR to meet specific
    requirements. I am working with various US Government agencies on various
    ISO 15000-5 projects. 
    
    Whether we like it or not, ISO 15000-5 and 11179 are being specified in
    multiple governments RFPs now in the US, Europe, Australia, New Zealand, and
    Asia. In the past month I have attended meetings in New Delhi and Sydney
    where some of this standards development work is being done by various
    government bodies as well as private industries. Sooner rather than later,
    there will be an interest in using these standards for EM TC messages. When
    to bite the bullet, what approach to use, and how to move forward at the
    same time to prevent a plethora of proprietary vendor and in-house developed
    solutions are the real questions that need to be discussed and answered. 
    
    I believe this requires a lot more discussion and consideration of the
    various approaches and results that one approach over another will produce.
    I hope that I can be available to participate in those discussions.
    
    Sylvia Webb 
    GEFEG US 
    310-370-3410 - Voice
    310-370-5614 - Fax 
    www.gefeg.com -  Internet 
    
    


  • 13.  RE: [emergency] HAVE draft comment posted

    Posted 11-02-2006 17:21
    Thanks Sylvia,
    
    I was not aware of the extent of international adoption, though I was 
    aware that ISO 11179 and ISO 15000-5 were getting traction. I was 
    actually more concerned that we make our specs more compatible with 
    business process automation in bpel, wsbpel, ebXML 
    registry/repository, and ubl, though all of this needs to work 
    together, hence my suggestion of an EDXL_RIM which will make it 
    relatively easy to build translation tables to accommodate 
    terminology remediation backwards and forwards, and takes the 
    immediate time constraint out of play for both HAVE and Resource 
    Messaging short term and Situational Awareness longer term.
    
    However, regardless, there is no easy way to accomplish what we need 
    to do, there are only choices between difficult and pains taking 
    options and whether we end up duplicating efforts for each of the 
    specifications we have already done in order to have consistent NDR 
    within HAVE and then retrofitting EDXL_DE. As has now been pointed 
    out, it is not simply a matter of incorporating NIEM as is without 
    significant consequences. Perhaps we can suggest asking a NIEM expert 
    to join our next TC meeting, and perhaps an ISO expert as well, not 
    that you are not an expert yourself, Sylvia. But it might be best to 
    have a non-TC, possibly non-OASIS expert, or at least someone who 
    does not have a major vested interest in this TC work. I am certain 
    we can craft an EDXL_RIM with an NDR that is both NIEM and ISO 11179 
    and 15000-5 compatible, or that can produce translations of existing 
    specifications that are compatible.
    
    Cheers,
    Rex
    
    At 8:36 AM -0800 11/2/06, Sylvia Webb wrote:
    >Hi Rex,
    >
    >Although I haven't been able to be active in the TC, I continue to try to
    >keep up with it's work. This particular topic is one that I cannot keep
    >silent on since software that supports ISO 11179 and it's practical
    >implementation, ISO 15000-5 are what my company creates software to for and
    >where I spend most of my time in the standards arena.
    >
    >Adding any NDR that supports ISO 11179 will not be a minor task. It isn't
    >something that can be done in a few months. Even with specialized tool
    >support it will take a dedicated team many hours of pains taking work.
    >Specifically adding the NIEM NDR may also produce a national solution
    >instead of a international solution.
    >
    >I believe that there is an approach that will support multiple NDR including
    >the NIEM and support the needs of the international community. Essentially,
    >it is proceeding with the RIM work that I believe you have already started
    >and incorporating ISO 15000-5 which includes support for ISO 11179-4.
    >
    >Simply adding the NIEM NDR will not achieve support for the wide variety of
    >requirements that the OASIS community will need. The NIEM NDR is a schema
    >representation of a data model. In order to support the needs of an
    >international community, you need a syntax neutral representation of the NDR
    >first. ISO 15000-5 is a syntax neutral representation of 11179.
    >Additionally, when the GJXDM was in development, many of the data
    >requirements were submitted to UN/CEFACT and subsequently to ISO for
    >inclusion in the current version of 15000-5. From the syntax neutral
    >representation, you can have any number of NDR to meet specific
    >requirements. I am working with various US Government agencies on various
    >ISO 15000-5 projects.
    >
    >Whether we like it or not, ISO 15000-5 and 11179 are being specified in
    >multiple governments RFPs now in the US, Europe, Australia, New Zealand, and
    >Asia. In the past month I have attended meetings in New Delhi and Sydney
    >where some of this standards development work is being done by various
    >government bodies as well as private industries. Sooner rather than later,
    >there will be an interest in using these standards for EM TC messages. When
    >to bite the bullet, what approach to use, and how to move forward at the
    >same time to prevent a plethora of proprietary vendor and in-house developed
    >solutions are the real questions that need to be discussed and answered.
    >
    >I believe this requires a lot more discussion and consideration of the
    >various approaches and results that one approach over another will produce.
    >I hope that I can be available to participate in those discussions.
    >
    >Sylvia Webb
    >GEFEG US
    >310-370-3410 - Voice
    >310-370-5614 - Fax
    >www.gefeg.com -  Internet
    >
    >