[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]