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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-msg message

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


Subject: RE: [emergency-msg] Groups - EM-Msg SC Meeting added


Hi everyone,

My 2-cents are that we need to strike a balance between most desirable and
most doable to publish the OASIS specification.  Overall the approach we
must take is to define what must be in the spec to move it out, do
everything possible before and during the FtoF, and aggressively pursue
outstanding issues and action items still on the table following the FtoF.

Now, I haven't developed any of the message sections as Karen and Rex have
so I don't have a good feel for it.  Regarding the individual message
structure diagrams, I feel it's paramount to include these models.  We do
need to determine what we can commit to before the meeting, but I fall into
the camp with Gary.  I see these diagrams as invaluable for clarity and ease
of reference, but the schemas with all the def's and constraints can be
pulled by the users for implementation.  It would be really nice to have
what Rex describes below, but I don't think it's required to produce a good,
usable OASIS spec (although I stand ready to concede that I may not fully
understand the breadth of the issue).  If we have a question of schema
testing or QA, let's discuss how to address that for production of the spec.

So, I don't see toolset as a big issue whether it's visio, ArgoUML, or
another tool. I say pick a tool and convention, start with the element
reference model as the template, and copy/tailor for each message. The same
tool and conventions should be used for all.

Looking forward to 4:00.

Thanks,
Tim


-----Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com] 
Sent: Monday, November 20, 2006 10:07 AM
To: Ham, Gary A
Cc: emergency-msg@lists.oasis-open.org
Subject: RE: [emergency-msg] Groups - EM-Msg SC Meeting added

We should probably discuss this, if we can find some time to spare 
for it. I lean toward making the DOMs purely normative so tools can 
grab n go. I'm pushing for standard object libraries for standards 
included in the registry I'm building so developers can have 
app-ready libraries.

For me, and this is obviously a personal opinion, I think we can make 
adoption darn near unavoidable if we make it easy through "standard" 
libraries and DOMs for developers to have Web Application using Web 
Services all but build themselves.

  I put quotes around "standard" libraries, because I don't expect the 
TC to develop any such thing, but the Member Section could and 
should. However, these libraries can't actually be Standard with a 
cap S. They can be offered as ibraries of specification-compliant 
object libraries like JSP tag libraries.

It also encourages real interoperability by making it easier.

The recent rapid development of AJAX really put us on the spot in the 
Web Services arena in general and in particular in the OASIS Web 
Services for Remote Portlets TC, where IBM, Sun, Oracle, BEA et al 
devote actual paid time to develop and test the standards. It has 
bitten us in the rear end while we spent cycles and cycles fussing 
over the niceties of whether or not to invent transient properties 
and where and how to use em. AJAX just left us in the dust to adapt 
as best we can.

It's the handwriting on the wall: If we don't keep ahead, we'll never 
catch up with the developers out there who will go ahead and build 
anything they think, or their marketing bosses tell them, they need.

And they will do it in ways that we can just about guarantee won't 
encourage the kind of interoperability we are searching for as 
opposed to say the kind of interoperability one can get by rolling 
the dice for whether or not the PHP tags one uses will be handled the 
way one wants them to be handled on a given web server.

I hope I don't break my neck getting down off this soap box.

Cheers,
Rex

At 8:28 AM -0500 11/20/06, Ham, Gary A wrote:
>  Actually, I prefer to think of them as "graphic message structure
>diagrams" as opposed to DOMs.  I.e., the schema is paramount.  The "DOM"
>is just an illustration for clarity. None-the-less a very useful
>illustration for clarity.
>
>
>Gary A. Ham
>Senior Research Scientist
>Battelle Memorial Institute
>540-288-5611 (office)
>703-869-6241 (cell)
>"You would be surprised what you can accomplish when you do not care who
>gets the credit." - Harry S. Truman
>
>-----Original Message-----
>From: Tim Grapes [mailto:tgrapes@evotecinc.com]
>Sent: Friday, November 17, 2006 3:57 PM
>To: rexb@starbourne.com
>Cc: emergency-msg@lists.oasis-open.org
>Subject: RE: [emergency-msg] Groups - EM-Msg SC Meeting added
>
>Maybe I missed something...  I didn't think DOM development for each
>message was off the table; just that it would be challenging to get them
>done before the FtoF.  I think it's critical that the DOMs be developed.
>
>Thanks,
>Tim
>
>
>-----Original Message-----
>From: rexb@starbourne.com [mailto:rexb@starbourne.com]
>Sent: Friday, November 17, 2006 12:51 PM
>To: emergency-msg@lists.oasis-open.org
>Subject: [emergency-msg] Groups - EM-Msg SC Meeting added
>
>I highlighted being REALISTIC about where we will be with the document
>going into the F2F because I DON'T think, given recent activities, that
>we will have ANY DOMs and perhaps no schemas. Without DOMs, relying
>solely on schemas, I think we can expect a wide variance in
>applications, which, given the number of message types, is asking for
>problems. If everyone builds their own, or lets them be determined as de
>facto outcomes of unstructured applications built solely on schemas and
>the data dictionary, I think we court having a mess. I intensely dislike
>DOM-based development, but they do enforce common structures, and that
>means ongoing INTEROPERABILITY in fact, versus theory.
>
>  -- Rex Brooks*
>
>
>EM-Msg SC Meeting has been added by Rex Brooks*
>
>Date:  Monday, 20 November 2006
>Time:  04:00pm - 05:00pm ET
>
>Event Description:
>Dial-in Number:  1-641-696-6699  (Iowa) 
>Access Code	 345450
>
>Agenda:
>1. Approve Minutes of previous meeting.
>2. Review latest draft of EDXL_RM.
>3. Determine goals for F2F wrt EDXL_RM, including REALISTIC asessment of
>where we will be going in.
>4. Mke a list of issues to be addressed as Karen noted.
>5. Focus activities that leverage group participation.
>
>Minutes:
>
>
>View event details:
>http://www.oasis-open.org/apps/org/workgroup/emergency-msg/event.php?eve
>nt_i
>d=12988
>
>PLEASE NOTE:  If the above link does not work for you, your email
>application may be breaking the link into two pieces.  You may be able
>to copy and paste the entire link address into the address field of your
>web browser.
>
>
>--
>No virus found in this incoming message.
>Checked by AVG Free Edition.
>Version: 7.1.409 / Virus Database: 268.14.6/536 - Release Date:
>11/16/2006
>
>
>
>--
>No virus found in this outgoing message.
>Checked by AVG Free Edition.
>Version: 7.1.409 / Virus Database: 268.14.6/536 - Release Date:
>11/16/2006
>


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

-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.14.10/541 - Release Date: 11/20/2006
 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.14.10/541 - Release Date: 11/20/2006
 



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