MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Fwd: Re: IF SC Assignment Updated List
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]