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
