Re: [emergency-msg] Backward compatibility

[Rex Brooks <rexb@starbourne.com>]

Hi Folks,

I kept out of this thread because I was just plum too darn busy and I 
knew it would be getting me into more discussion and therefore more 
time I could not afford at that time for a number of reasons. 
However, since we are going to be having a meeting today where we can 
air this, I thought I would add my $.04 on this (two $.02 
opinions/observations).

First, schema writers, standards framers, need to stay out of app 
writing mode while writing schema or framing standards, even while 
they use it as the basis for driving requirements and even if 
individuals have to wear both hats. I've been through this 
discussions too many times, but the primary reason is that the 
thinking about "hardcoding specs" contaminates writing those specs 
because those specs start getting written to specific coding styles 
and toolsets. Bad. Bad. Bad. Had my knuckles slapped sooo hard on 
this, I learned it. This is, of course, about as difficult a task as 
there is, so it requires the standard disclaimer--We have to walk the 
tightrope of balance on this because it can't be done in absolute 
terms.

Now to understand just how difficult this is, try writing a protocol 
that is, in effect, really just a large API that applies to .Net, 
Java and all flavors of open source (Linux or Linux-based 
environments, such as those using solely PHP, MySQL and Python) and 
keep in mind that ALL terms must equally suited for all platform and 
platform configurations in completely heterogenous network (web) 
configurations. (Check WSRP 1.0 for an example, for which I happen to 
be sweating bullets in the effort to write the markup section of a 
Primer.)

Second, while it is bad policy to use the exigencies of coding 
(platforms, toolsets, etc.), even beginning to adopt any kind of 
official policy about DOs and DON'Ts for app coders, will get us 
bogged down in religious arguments that have no place in agnostic 
environments, or environments that need to remain agnostic. However, 
that said, if we write schemata, we are expecting the those terms in 
our namespace to be USED in app coding. That's what they are there 
for. (Yup, ended a sentence in a preposition.)

That's my $.04.
Rex

At 11:31 PM -0400 10/6/03, R. Allen Wyke wrote:
>On Fri, 2003-10-03 at 18:40, Art Botterell wrote:
>>  At 5:24 PM -0400 10/3/03, R. Allen Wyke wrote:
>>  >From a system/application design standpoint, the approach of hardcoding
>>  >the support for a schema in an app is not wise and is very short
>>  >sighted. It locks you into a single version of a standard, or at least
>>  >makes it hard to support newer versions, because it means your system
>>  >must be updated to support the newer versions.
>>
>>  I agree... but some degree of hardcoding is the reality for anyone
>>  who deploys in firmware... which is to say, for the majority of folks
>>  deploying consumer devices.  Hopefully most such systems will have
>>  some provision for updating their receivers, but that's not something
>>  we get to dictate.
>
>Fair enough, and I agree we need to consider it.
>
>>  This was the larger point to my earlier comment about web services.
>>  Those of us who work in the networked-computer world need to make an
>>  extra effort to remember the needs of stakeholders in other
>>  industries.  OASIS is heavily weighted toward the IT industry, but
>>  CAP in particular has a much wider constituency.  If we don't address
>>  the needs of folks outside the IT mainstream, we risk forcing them to
>>  create their own divergent standards.  That would be regrettable and
>>  counterproductive, and it seems unnecessary.
>
>My only issue, or rather observation, is that if it is in fact important
>to "wider constituency", then why are they not on the TC? To some
>degree, while we certainly have obligations larger than we each bring,
>it is unfair for the paying members to spend more time trying to address
>people who do not appear to care enough to participate, rather than
>focus on the group that does.
>Clearly this is a fine line to walk, and I believe there is a way to do
>it gracefully, but I think this is accomplished by 1) being
>understanding to their needs in our efforts, but also 2) being honest
>with them that to truly address their needs we need their expertise and
>contribution on the TC.
>
>>  - 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