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

[Rex Brooks <rexb@starbourne.com>]

Hi Gary,

First, even I would not hold out for what I have been discussing, but 
for the sake of discussion, my further comments are inline.

At 10:54 AM -0500 11/20/06, Ham, Gary A wrote:
>Rex,
>
>I know how to use a schema for validation.  I can even see how it could
>be auto-loaded into a model as a DOM.  If you want the DOM to be
>normative, what you have to do is provide a simple, easy to navigate for
>programmers, free-to-use, method for validating that guarantees that it
>will also validate against the schema.  In such a case I would probably
>agree 100% with you.  I am just not sure where you are going.  I general
>think of DOMs in terms of Java or Data modeling. (Limitation of my
>background, I suspect.) For Java, a DOM is easy to load, but programmers
>would have to separately code many of content restrictions that are more
>easily enforceable by simply applying schema validation. As a data
>model, I can generate a lot of good "stuff" (including different forms
>of schema, relational, XML, etc.). To me, the model, as we have been
>using it, is still only a very useful graphical technique for defining a
>data structure.  Models can, with strict discipline imposed, become the
>basis for very real schemas, but the discipline is sometimes harder to
>see in the model than it is in the schema that the model is designed to
>represent.  This is why UML had to develop Object Constraint Language
>(OCL).  The pictures alone were simply not enough.

Agreed. The DOM as part of a set of models can output the Java 
class/object structure.

>Question: Is your notion of DOM more, less, or at the same level of
>restrictiveness as an XML schema?  I would guess that it offers more
>control, rather than less, but I am not sure from your discussion.

MUCH More restrictive than XML Schema. You can't allow wiggle room 
going from visual diagram to programming or programmable code, both 
for object classes and methods, especially methods. We don't want 
wandering methods. Where did ya call it, where does it report, etc. 
(I'm speaking Java, not DotNet--that's a whole nutter conversation.)

>Our current way of thinking has been somewhat less restrictive.  With
>added modeling discipline we could accomplish equivalence.  The more
>restrictive approach would pave the way to direct model-driven
>development, which is not a bad thing, but appears to me to be two steps
>in front of what we need to accomplish to get our specification
>finished. I am also afraid that it would take just about 4 times as
>long.

Agreed. This is downstream stuff for 2.x and later, after we get a 
RIM, if we do. This is stuff folks like IBM do well, and it takes all 
the guesswork out. That's what I think we would like. However, it CAN 
restrict the market, unless we get it donated to places like Eclipse 
Foundation and/or the JSR community.

THAT's where I think an effort in our own Member Section could make 
that kind of matching effort and contribution valuable to the likes 
of IBM and Oracle because it plays into their open-source-based 
marketing. AND, once it gets into that kind of more-or-less 
open-source structure, if it gets there, we good interoperability 
WITH the option for relatively low-cost entry which stimulates 
innovation.

Cheers,
Rex (the pie-eyed dreamer)

>R/s
>
>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: 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?ev
>>e
>>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


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