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] ICS form req's draft


At 8:33 AM -0400 7/18/03, Allen Wyke wrote:
>Maybe I am not understanding "how" you are planning on using the 
>subset. Are you proposing to use the same structure as used in CAP, 
>OR are you saying to use CAP ("connection" implies use CAP)?

How can I  say this any more plainly? Nobody has suggested importing 
any structure from any other schema.  (In fact, structure hasn't been 
discussed at all... that's a later step in the SC's agreed-upon 
process.)  All that has been suggested is that certain elements that 
were used elsewhere might also be useful in the new (ICS-201) schema. 
To enumerate, we're talking about some or all of:

Message ID (identifier)
Sender ID (sender)
Sent Date/Time (sent)
Status (status)
Scope (scope)
Type (msgType)
Password (password)
Operator/Device ID (source)
Restriction (restriction)
Address (address)
Handling Code (code)
Note (note)
Reference ID (reference)
Incident ID (incident)

If (and only if) we decide that some or all of those elements would 
be useful in the ICS format, then the next question will be how best 
to implement that.  We could create a joint data dictionary, as has 
been suggested on several occasions.  Or we could create a 
spaghetti-plate of inter-schema references, although that wouldn't be 
my recommendation.  Or we could simply include identical element 
names and definitions in the new spec, which would be inelegant, 
perhaps, but quick and simple for purposes of discussion, and easily 
transformed into a more elegant formulation later.

But those are two separate questions; until we decide there's 
actually a need for some or all of those elements, it seems premature 
to argue about the mechanics of including them.  What's on the table 
right now is a requirements document, which by definition focuses on 
"what" rather than "how."

Of course, if someone in the TC or the IF SC wants to bring forward a 
constructive process proposal on how the TC should do this sort of 
thing globally, that would be wonderful.  But this SC has been asked 
to move ahead, and in the absence of a TC policy we've tried to do so 
in the simplest, quickest and most transparent way we can devise.

I appreciate everyone's cooperation and assistance in getting so much 
productive work done so quickly so far, and I very much hope we'll be 
able to proceed in the same spirit.

- Art



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