Re: Status of the CALSCH working group (Alarms/SEQUENCE)

George replied on 11/11/2003 05:28:10 PM:
> What if
> a) The CUA doesn't allow repeats?
> b) Or doesn't allow repeats with a duration anywhere as short as 1 
second?
> c) Or allows them, but to get them you have to use some advanced 
function
>    that the user doesn't know or doesn't want to know?

All interesting questions / scenarios.  I would think that any CUA capable 
of distinguishing between 20 identical duplicate alarms would allow 
something like repeats but perhaps not.  Still though they are valid 
questions...

> I fail to see the harm in duplicate alarms, and judging from the 
discussions
> I've read in the archive, I think the matter was considered by many 
other
> people, and unique ids for alarms were considered a good thing.  Yeah, 
sure,
> we can reconsider it, but if you're interested in doing the simplest 
thing,
> reopening old issues isn't what you want to be doing.

The only thing that I question regarding the original discussion was the 
practicality of multiple exact duplicates considering its not something 
available in any shipping product now that Im aware of.

In any case, I do question the undiscussed change of ALARMID to SEQUENCE 
(including the misreuse of SEQUENCE as an identifier instead of a change 
tracker).  In evaluating the actual application I also came up with the 4 
questions I posted before. 

Contrary to WG discussion before, I think the ABNF for this change needs 
to be '0' or '1', not '1' for technical reasons previously mentioned. 
Doing this and making it clear that the identifer is ONLY for BOOKED 
entries and is never sent as part of workflow should resolve 'em I think. 
However Im interested to hear if there are alternate ideas.

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email protected]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...