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] Information Model


Hi Renato,

I already lodged a request to remove the specific namespace IDs from 
the FEMA-derived specific components, and those are all related to a 
single part of a specifically funded pilot project. We are under a 
LOT of pressure from the Homeland Security and Defense 
establishments, passing along the pressure they are feeling 
politically to simply, and relatively mindlessly DO SOMETHING! which 
always produces work even worse (proprietary as well as completely 
US-centric) than the worst we could do.

Regardless, an information model by itself, as opposed to the DOM we 
work on next, is not going to fly for this group, and will greatly 
confuse the process which we have already established, against some 
opposition even if unvoiced, to avoid the kind of confusion we 
suffered through with DE. So, I suggest working at the nuts and bolts 
level for now, and taking notes for an EDXL-wide RIM as opposed to 
another specification-specific IM that gets wrapped around further 
confusion with the DOM, which is established as a fundamental  part 
and parcel of the RE, which I thought was supposed to RM, or would it 
be RME for Resource Messaging Element? Hereon referred to as 
RE/RM/RME.

Further, I just happen to disagree with moving those types up to a 
higher level, which I think should be  reserved for three categories 
of messages: Request, Response, and Other as the higher orders to 
which these specific message types naturally belong.

However, even that should be held in abeyance until we know what 
happened at the last meeting, last week, when the remaining first 
draft of the data dictionary was to have been gone through, if at all 
possible. The goal, remember, is to have a first draft by May 9-12 
for the face-to-face meetings at the OASIS Symposium in San 
Francisco, CA. We are planning to have the first draft DOM at our 
next meeting, based on what was learned by working through the first 
draft of the data dictionary. If it seems like I am stressing first 
draft, that's because we set the process up this way: 
Requirements>DataDictionary-Draft1>DOM-Draft1>Spec-Draft1>F2F.

Is there any chance you could get funding for traveling to this event?

You might want to point out that this is actually acutely important 
to Australia as well as the US since Australia shares the two main 
recurring natural disasters we have to deal with on an annual basis, 
cyclones/hurricanes and wildfires. That makes Australia the best 
place, as opposed to Europe or even Canada or Mexico to test out the 
International aspects of these specs in an annual way just because 
both governments know they have to spend money every year on these 
two kinds of purely expectable natural phenomena, so these two 
countries, even as widely separated geospatially in terms of both raw 
mileage and Coordinate Reference Systems.

Also, like it or not, you are about to have the other hyperactive 
planetwide 800-lb. gorilla superpower, (in terms of expanding its 
economic sphere of influence by projecting raw military power), 
China, on your doorstep for the next few decades, so you are going to 
have your own Defense mania all too soon, above what you have now.

It's unavoidable, and the Defense Crowd wait for no one, especially 
where substantial profits are involved, so let's try avoid in the 
here and now, from getting confused again, in this little TC  where 
we have some small ability to influence the world. This is, as you 
say, especially important because the RE/RM/RME is larger, though 
considerably less complex in its ramifications, than the DE, since it 
won't encounter real problems negotiating up and down through the OSI 
stack as reflected in the every changing web stacks.

I would like to work with you on an RIM based on what we have seen in 
the DE and will see in the RE/RM/RME which can then serve to model 
the remaining components of the EDXL.

Ciao,
Rex

At 1:56 PM +1000 4/3/06, Renato Iannella wrote:
>(Sorry for delay in response, but have been traveling for the past 10 days...)
>
>My (1st) concern is that we are jumping into the data dictionary 
>without yet looking at
>what the information model looks like. The RE is a lot more 
>complicated than the DE
>as the RE has more of a "protocol" structure (request, respone, ack etc)
>
>As an example, I don' think we should have a "type" element with these values:
>"Request Resource
>Requisition Resource
>Commit Resource
>Request Information
>Offer Unsolicited Resources
>Release Resource
>Request Resource Return
>Request Quote
>Request Resource Disposition
>Notify Resource Request Disposition
>Notify Auxiliary Recipients"
>
>But, these should all be first-class elements.
>
>I am happy to have a first go at the information model.
>
>My (2nd) concern is that this is supposed to be an international standard?
>I don't think that the "FEMA*" elements contribute towards this goal.
>
>
>Cheers...  Renato Iannella
>National ICT Australia (NICTA)
>
>
>
>--------------------------------------------------------------------------
>This email and any attachments may be confidential. They may contain legally
>privileged information or copyright material. You should not read, copy,
>use or disclose them without authorisation. If you are not an intended
>recipient, please contact us at once by return email and then delete both
>messages. We do not accept liability in connection with computer virus,
>data corruption, delay, interruption, unauthorised access or unauthorised
>amendment. This notice should not be removed.
>
>---------------------------------------------------------------------
>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


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


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