OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [emergency] EDXL-HAVE and SOA / B2B use cases / implementation models


Rex et al,

I left David off this response to first determine whether the TC agrees with
my comment.  I have also heard similar comments regarding the size of the
standards (payload size) discussed referencing the term "microformats".  I
tend to use the term "profiles" here.

Setting aside David's comment regarding a query message, I believe a need
for smaller "lean and mean" messages can be accommodated in accordance with
the present HAVE standard architecture through implementation of profiles.
HAVE contains only a handful of mandatory elements, allowing implementers to
create "profiles" to suit their needs.  By profiles I mean subsets of the
overall "reference schema" built in accordance with all requirements of the
specification.  Put another way these are smaller "constraint" schemas built
off of the overall standard "reference schema".  A profile can be any size -
very small if needed to meet a particular exchange purpose.  

In the case of RM I realize the TC choose to explicitly define several of
these "profiles" (individual RM message types) within the spec.  But we'll
never predict all possible needs, and the current standards do not preclude
implementations from developing their own profiles/constraint schemas - as
long as they adhere to the core standard definitions and rules.

Thanks,

Tim


-----Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com] 
Sent: Tuesday, December 11, 2007 2:11 PM
To: David RR Webber (XML)
Cc: emergency@lists.oasis-open.org
Subject: [emergency] EDXL-HAVE and SOA / B2B use cases / implementation
models

Hi David,

I took an action item in today's Emergency Management TC Meeting to 
respond to your two messages. We did not have a quorum, but we can 
vote in our next meeting after the Second 60-Day Public Review of 
EDXL-HAVE has expired to accept this response as a valid resolution 
to the issue presented by your Public Comment copied below.

There are two responses to this:
1. We were not tasked with scoping our work to address modern SOA and 
B2B best practices; but,
2. If this were not a specification which is finishing its 2nd 60-Day 
Public Review, and if critical demand for this specification had not 
been repeatedly stressed upon us, (by HITSP among others) we would 
consider accepting your issues.

So, for now we choose to defer. However EDXL-Resource Messaging 
(EDXL-RM) actually provides the Message Exchange Patterns you 
mention. It is a couple of months behind EDXL-HAVE.

We will certainly consider adding such considerations in the next 
version of EDXL-HAVE, but, in our opinion, the need for it is too 
great to delay it based on these considerations.

That said, since I happen to be a member of the OASIS SOA Reference 
Model TC, I can appreciate your concern, but I don't think this is 
nearly as much of an encumbrance as you suggest.

We would welcome your assistance in building sample CAM templates to 
show how your suggestions can be done with the existing specification.

The EDXL-Resource Messaging (EDXL-RM) Specification will soon be 
ready its 2nd 60-Day Public Review.  EDXL-RM is based on the overall 
Resource Message Type, with 16 specific Message Types.

These include a number of Requests and Responses, as well as Reports 
which may become its own specification with EDXL-HAVE as a model.

I am editing the current version of EDXL-RM 1.0 which we will, 
hopefully, finish at our upcoming workgroup face-to-face meetings 
January 8,9,10 in Washington, D.C.

EDXL-DE 1.0 handles the Routing/Distribution of Emergency Messages 
and is being implemented by the Integrated Public Alert and Warning 
System (IPAWS) and we are using what we learn in that effort to 
provide some of the requirements for EDXL-DE 1.1.

The whole EDXL Family has at least two and maybe three more 
specifications working their way through the practitioner-SME group 
process that leads up to submitting it to the TC for the TC to decide 
on accepting or not.

We are also planning an EDXL-Reference Information Model (EDXL-RIM) 
which will formalize the various kinds of messages and mechanisms in 
the whole family at a more abstract level than the specifications. It 
is preliminarily planned to include an RDF Schema and an OWL-DL 
representation in addition to an XML Schema.

Cheers,
Rex Brooks



Subject: EDXL-HAVE and SOA / B2B use cases / implementation models

     * From: "David RR Webber \(XML\)" <david@drrw.info>
     * To: emergency-comment@lists.oasis-open.org
     * Date: Sun, 04 Nov 2007 16:40:27 -0700

Having looked at your XSD - I'm just not seeing the connection here 
to modern SOA and B2B best practices.

Frankly - if I were a hospital adminstrator - I'd have a real hard 
time understanding how I'd adopt this - and build it into emergency 
dashboarding.

The problem is that this is an "all or nothing" information exchange 
model - that seems at odds with a service based or B2B collaborative 
partner model.

In the B2B model - I'd want to send out hourly bulletins on status 
changes - and hence use lean-and-mean messages with just essentials 
that new data requires.

In a SOA service model - I'd expect to do a query / response exchange 
- where I'd send out requests to my group of partners (actually this 
is a nice B2B / ebXML shared routing example too - rather than 
point-to-point SOAP webservices).

So what we're missing is that query message.  This could be based off 
the xsd you have - simply put a message_type on there - and then 
include the sections you want status on as empty tags - for a simple 
first cut at this.

You may want to get more sophisticated and include specific service 
empty tags below that parent.

The responding systems would then "fill-in" those empty tags - as 
responding information.

Again - you can easily build CAM templates for this interaction model 
- but you will need to change your schema to make things optional - 
and then provide the CAM template for the particular interchange 
context to make clear the exact content model(s).

Thanks, DW



-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]