OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [emergency] Groups - EDIT of emergency-CAPv-1.1


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]