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

On Mon, 2005-03-07 at 14:43 -0500, Art Botterell wrote:
> The enumerations are, in fact, a normative component of the spec, so 
> I'm not sure how this would make much difference... except by 
> creating new opportunities for configuration control errors.  Anyway, 

It makes quite a big difference in terms of keeping things modular vs.
static, as I laid it out. I'm curious to know what kind of configuration
control error would be caused by using a normative reference/lookup

Internally one has to validate values regardless of format, and either
method is prone to error. 

In fact, I'd be willing to bet that a list of enumerated values is more
prone to error than a lookup table.

> do we really want to get into recommending how folks should structure 
> their implementations?

We already do by way of the hardcoded list. Not to say people could
still not hardcode their lists if they wanted to - but at least it would
give people more flexibility in terms of implementations and actually
force them to write more solid implementations.

> We're considering a more modular approach along those lines for EDXL, 
> but that's a different context.  CAP is intended to be a lightweight 
> format suited to embedded devices as well as full-functioning XML 
> processors.

I'm not sure how an embedded system would be unable to cope with a
lookup table, even with a binary translation of the schema and/or data.

For an embedded system that can take a update, lookup tables are the
best way to go. For those systems that cannot handle any code update -
they would run exactly the same way as the existing system. 

Using a lookup table doesn't imply the need for some kind of re-writable
storage on any CAP processor.

> Anyway, a change to the enumerations is a change to the standard, so 
> why not have them in the schema so validators can determine the 
> validity of CAP documents?

The schema validator isn't going to determine validity of the CAP file's
data - its only part of the processing procedure. Same thing with using
a schema+table.

I'd be happy to put together a list of advantages vs disadvantages of
both approaches. I've implemented this enough times in different
permutations already to say off the bat that a lookup table's advantages
far outweigh whatever a fixed internal list can offer.


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