[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency] Groups - EDIT of emergency-CAPv-1.1
On Tue, 2005-03-08 at 10:51 -0800, Art Botterell wrote: > Well, strictly speaking I don't... the burden of persuasion is on the > proponent. However, I've tried to explain why I don't think this > change is necessary or appropriate at this time. Whether or not you > consider mine to be a "good" answer is up to you. You've given a lot of 'no' answers but never any solid reasons. > Anyway, now that this has been recast as a 2.0 issue we can consider > it in the context of EDXL and at a more appropriate time. Ah, the push-off. Which is exactly how this concluded the last time I brought it up. Except now we actually have a real-life example. What a waste of time. > >'Things will not interoperate' doesn't qualify as a valid > >answer (or excuse). > > Excuse me? If interoperability isn't a good answer/excuse, what is > it we're doing here? See my first comment. > Maybe we need to review the purpose of the "category" element: it's > to provide a simple and predictable taxonomy of events that automated > systems can use to select an appropriate response to receipt of a > particular message. CAP also provides the "event" element to permit > free-form descriptions, but those aren't predictable enough for many > implementions to rely on. What does a predictable taxonomy of events have to do with a lookup table? A lookup table is just a structure for said data, it can't infer any level of complexity besides the fact that you have to implement it. > >This is right up there with accusing me of using this to push an > >implementation issue to the standards level. What's up with this? > > This pattern of casting a professional discussion in personal terms > is one I've seen increasingly in this TC, and I think it's really > regrettable. Then stop doing it. Your comments were out of line. I am not paid to be on this group and my membership dues are on my own personal dime. > No such general equation is suggested.... but your previous note > struck me, at least, as suggesting pretty clearly that anyone would > be able to add values whenever they were ready and that only "if Dave > needs to be interoperable" would such additions be submitted to the > standards process. If I misunderstood you, I apologize, but if I > have that right then, yes, I believe it could lead to a significant > loss of interoperability. As it is, there is a loss in interoperability because the spec does not currently have a CBRN category. So this is a moot point. At least with abstracting these element lists you keep the core clean and keep the lists potentially easily extensible without many code-level changes being required. Making a change to a table although still out of spec has much less of an impact on parsers (by parsers I mean machine) than does making a change to the core schema, because by the nature of implementing a parser for tables you are forced to handle these element structures in a way that makes it easy to modify if new elements are introduced (as opposed to having to handler code at all). > Neither. I'm just not yet persuaded that there's a substantial > problem here in the first place. And philosophically I'm concerned > about the potential water-muddying consequences of making unnecessary > changes. If you fail to be convinced then I quite literally give up. I have already wrappered what I consider 'bad spec' at the code level. At least I can deal with new elements now as they are introduced, and not have to make any changes to my code. I can't say if this is the same about other implementations (but that is their problem, right?). Cheers Kon
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]