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] Backward compatibility


A few thoughts have occurred to me wrt this discussion.

First, it took me a while to connect Consultrac with Rick, so if 
anyone in the future is making a significant move or even just making 
a minor change in the edrress being used, a note announcing it to the 
TC at the same time one changes it as part of one's OASIS activities 
would be appreciated. I had only just disabled all remaining spam 
filters because I missed an important piece of mail last week that a 
colleague had made such a change. Consultrac would have fallen into 
one of those abysses otherwise and if yesterday had not been busy, I 
might have weeded it out by accident since my delete trigger is often 
faster than my perception so I might not have gotten to the subject 
line from an unknown sender line before deleting it. This has 
occurred often enough now that it is a toss up as to which is worst, 
filters or manual deletion of spam.

Second, I thought that the mandate for infrastructure included all 
aspects of our work. My thoughts in response to Art's comment are 
that Notification and Messaging are one aspect, and this is not in 
any sense scope creep. The same thought appolies to GIS as well.

My own commentary on the original piece was still in process, but 
since I am getting busier until my next reprioritzation, I am going 
to include those thoughts here.

So in line with the fact that all of our work depends on 
infrastructure, I would suggest that we include a specific set of 
requirements from our TC to W3C XML Transport Protocol Working Group. 
My requirements would be for at least two kinds of functionality in 
XMLTP (in addition to being a kind of traffic control switch amongst 
existing transport protocols as will be seen in my set of 
requirements). Those two kinds of functionality would be synchronous 
and aynchornous messaging--in a secure signal stream separate from 
http and IM, both of which should be callable from XMLTP to transfer 
functioning from one transport protocol to another based on a set of 
criteria comprised of;
	1 - SOAP calls to http, with secure SOAP calls to  https;
	2 - non-critical (i.e. cirucmstantial and ansynchornous 
updates such as changing stock prices)
	messaging to secure IM;
	3 - critical (Emergency Management high priority-severe 
rated, and synchornous) messaging
	kept within secure XMLTP;  and,
	4 - noncritical asynchronous messaging kept within less secure XMLTP.

This would give us in effect our own secure channel for EM (3 above) 
AND this would be truly global, so the door would be open for the 
creation of faster more localized internationalization and 
localization.

The web services comment was too far out of context for me to 
understand it. I backtracked as best I could and it still doesn't 
tally with backward compatibility of schemata. At its simplest all 
web services do is systematize the exchange of information from 
within various kinds of applications. WSDL is meant to sort out those 
kinds of compatibility problems by giving connected parties a common 
set of metadata about the services and applicatons. But it doesn't 
create compatibility or elminate lack of it.

Ciao,
Rex

At 7:24 AM -0400 10/2/03, R. Allen Wyke wrote:
>On Sat, 2003-09-20 at 16:40, Art Botterell wrote:
>>  At 4:20 PM -0400 9/20/03, R. Allen Wyke wrote:
>>  >Hmmmm, that certainly stimulates an interesting concept - addressing
>>  >people who *may* only want/can support just one version of the standard.
>>  >That they can't create a system that is upgradable.
>>
>>  Looking at it the other way... when there's a new version, will we be
>>  able to assume that every implementation will upgrade precisely at
>>  once?  Probably not... so some provision for backward compatibility
>>  will be needed anyway.
>
>Oh, absolutely. I *think* even the XML Recommendation states that new
>versions of XML-based languages should make all attempts to be backward
>compatible. The unspoken rule here is that if you can't, then you didn't
>architect it right the first time - that you tried to put too much in
>there, or tried to rush something.
>
>>  Regrettably, it's going to be awhile before the whole world runs on
>>  web services.
>
>Web Services? I'm sorry, I am not sure how this applies to this
>discussion (validation of schemas)?
>
>>  - Art
>>
>>  To unsubscribe from this mailing list (and be removed from the 
>>roster of the OASIS TC), go to 
>>http://www.oasis-open.org/apps/org/workgroup/emergency-msg/members/leave_workgroup.php.
>--
>R. Allen Wyke
>Chair, Emergency Management TC
>emtc@nc.rr.com
>http://www.oasis-open.org/committees/emergency
>
>
>To unsubscribe from this mailing list (and be removed from the 
>roster of the OASIS TC), go to 
>http://www.oasis-open.org/apps/org/workgroup/emergency-msg/members/leave_workgroup.php.


-- 
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request


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