Fwd: Re: IF SC Assignment Updated List

[Rex Brooks <rexb@starbourne.com>]

Hi Folks,

I neglected to "reply to all" with this, so I'm correcting that little slip.

Ciao,
Rex

>Date: Wed, 9 Nov 2005 07:30:15 -0800
>To: Renato Iannella <renato@nicta.com.au>
>From: Rex Brooks <rexb@starbourne.com>
>Subject: Re: IF SC Assignment Updated List
>Cc:
>Bcc:
>X-Attachments: :Macintosh HD:548647:EDXL_DE_Issues_11-07-#B25BB.xls:
>
>I just attached the updated Issues list. BTW, thanks for the 
>validation checks mentioned in your other recent email.
>
>No, at the top level there are just those four basic message types 
>or categories. We won't be adding new ones in that group at this 
>time unless the ballot to move the specification forward fails.
>
>In addition we have the two new text fields for Incident Name and 
>General Description and the four sensor specific message types or 
>categories. I added the word categories here because as we discussed 
>this, we were not specifically establishing "Types" with an upper 
>camel case "T" per se.
>
>The RDF effort spent nearly four years stuck in that pit, so please 
>let's not go there. We've been without a solid foundation for an 
>inference-capable semantic web for those four years, over an issue 
>or set of issues that, in the end, were merely a chimera.
>
>We should be careful to note that, and note also that, as with most 
>standards in XML, there needs to be the understanding that we can 
>revisit these or any issues to change or refine them, or add 
>specific extensibility mechanisms so that we should not be caught 
>answering the question "You mean Specification X ONLY allows these n 
>types?" I could probably think up a few apparently valid message 
>types at the drop of a hat, and coming up with these "possible 
>exceptions" is something that happens just before almost every final 
>vote to move a specification to its next stage. In fact, I would 
>probably feel compelled to initiate that process myself if it didn't 
>always spontaneously generate at that stage, so please don't think 
>that I consider it a bad thing--just an inevitable and, probably, a 
>good thing in terms of applying the principle of due diligence.
>
>It gets very easy to lose sight of those adaptive mechanisms when 
>one is writing and testing implementations, especially if one or 
>another major governmental body proclaims that compliance with 
>Specifications X, Y and Z is mandatory before those bodies have 
>themselves tested to see if those specifications validate against 
>each other and against the complete collection apparently required. 
>While we want to encourage adoption, we need the flexibility to find 
>ways to make these standards work together in the field as needed 
>because no group can anticipate all the ways in which protocols and 
>message formats will actually interoperate or attempt to 
>interoperate. This is still much more art than science, though I 
>think that with our pursuit of a fundamental use-case and 
>requirements methodology, we are advancing the cause of a more 
>scientific approach, at least in that methodology.
>
>Ciao,
>Rex
>
>>On 9 Nov 2005, at 01:25, Rex Brooks wrote:
>>
>>>On your #28 here (#19 in our EDXL_DE_Issues_11_07_05 Rev 01.xls 
>>>document posted to the Document Repository yesterday)
>>
>>Rex - could not see that document - Latest is dated 11-06-05 ?
>>(Are there two different DE Issues documents with different 
>>numbering systems??)
>>
>>>we specified the basic (e.g., non RM- or 
>>>otherEDXLComponent-specific) message types: update, cancel, ack or 
>>>error. That provides a handy way to distinguish between general 
>>>and specific.
>>
>>Rex - can you clarify this...
>>Are you saying DE will just have these 4 message types?
>>
>>Cheers...  Renato Iannella
>>National ICT Australia (NICTA)
>>
>>
>>
>>--------------------------------------------------------------------------
>>This email and any attachments may be confidential. They may contain legally
>>privileged information or copyright material. You should not read, copy,
>>use or disclose them without authorisation. If you are not an intended
>>recipient, please contact us at once by return email and then delete both
>>messages. We do not accept liability in connection with computer virus,
>>data corruption, delay, interruption, unauthorised access or unauthorised
>>amendment. This notice should not be removed.
>
>
>--
>
>Rex Brooks
>President, CEO
>Starbourne Communications Design
>GeoAddress: 1361-A Addison
>Berkeley, CA 94702
>Tel: 510-849-2309


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309

EDXL_DE_Issues_11-07-05 Rev 01.xls