At 9:44 AM -0800 3/18/05, Kon Wilms wrote:
>Well that assumes that they don't have the tables to start off with,
>which doesn't make sense.
No such assumption. The question is what happens when changes are
made that they don't have a way to know about or adapt to. Right
now, if a device is CAP 1.0 compliant, we know exactly what values it
knows about. And if CAP 1.1, we know it will also know about "CBRN"
(whether it will care is another question, of course.) And if the
device sees a version number it doesn't know, it knows something has
changed.
>Using tables forces the embedded developer to write code that will look
>at each field and parse it. Good code principles would dictate that
>exceptions (new elements) have to be handled.
See, this is what I meant about this being an application issue.
Sorry you took that personally, 'cause it really wasn't meant that
way. I just don't think it's appropriate to use the standard to try
to force folks toward particular coding practices, no matter how
correct we may believe them to be.
>Who said things were going to change suddenly or frequently? Its more of
>a case of 'in the event of a change which model would work better'.
I agree that they shouldn't change suddenly or frequently. But in
that case I'm not sure why we're spending so much time on what would
seem to be a non-problem.
>Which is why you make the enumerations part of the standard and stick
>them in it just as you do with the core schema.
Which is effectively what we do now, except with one fewer document
(and enabling a validating parser to enforce the enumerations.) I'm
just having trouble understanding what this change would buy us that
we want.
>Ok so there are two approaches.
No, there's also the option to use tables in some cases and
enumerations in others. But this gotta-be-one-way-or-the-other view
is what I meant earlier about a stylistic issue. Actually, I don't
have a strong opinion about the style question one way or the
other... actually, if CAP were some sprawling schema I might be
swayed by the comprehensibility argument... but underlying that
seemingly mechanical question are the various policy issues that Rex,
Tom and Len have raised.
Again, I think it's entirely appropriate for the TC to think through
these questions in the course of developing EDXL. Then we can take a
look at the specific implications for CAP when we do the 2.0
harmonization. It's really not a put-off, it's just not rushing into
something we don't need to.
- Art
