Re: [emergency-adopt] Re: A few fixes

[Rex Brooks <rexb@starbourne.com>]

Thanks so much, Dee,

It's good to be able to move this forward.

Cheers,
Rex

Dee Schur wrote:
> Hi Rex,
> I spoke with Mary regarding the white paper. This was originally a product
> of the EI Steering Committee and it is no problem to use this template,
> http://docs.oasis-open.org/templates/.
> There are no IPR restrictions on member sections, so just make certain to
> state that this is a product of the OASIS Emergency Interoperability Member
> Section and not the EM TC we are good to go!
> Best,
> Dee
>
>
> -----Original Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com] 
> Sent: Monday, July 27, 2009 11:59 PM
> To: Mary McRae
> Cc: Waters, Jeff CIV SPAWAR SSC PAC, 53621; Dee Schur; Carol Geyer;
> dellis@sandia.gov; emergency-adopt@lists.oasis-open.org
> Subject: [emergency-adopt] Re: A few fixes
>
> Hi Mary,
>
> Actually, the TC assigned the task of reviewing and suggesting changes 
> to the Infrastructure Framework SC, but I understand the need to conduct 
> these discussions on that list, so I am copying that list with this 
> message and we will conduct the rest of our discussions in that forum.
>
> Putting this document into the specification format is doable, since it 
> is not finished, but if the OASIS Board is going to review this policy, 
> I will suggest we wait for the result that review, and my personal 
> recommendation will have to be based on that outcome.
>
> Thanks for getting us back on track, Mary.
>
> Cheers,
> Rex
>
> Mary McRae wrote:
>   
>> For some reason this paper isn't being discussed on the TC list; any 
>> discussion with regard to the document must happen there. Once again, 
>> this template is not to be used for this document; the only approved 
>> document template for TC work is the specification template.
>>
>>
>>
>>
>>
>>
>>
>> On Jul 27, 2009, at 1:36 PM, Waters, Jeff CIV SPAWAR SSC PAC, 53621 
>> wrote:
>>
>>     
>>> Hi, All:
>>>
>>>  I like the looks of this format very much.  Thanks to Rex and 
>>> everyone for making this paper so nice.
>>>
>>> I fixed a few items (see attached document with changes recorded), 
>>> but perhaps to an earlier Friday version than Rex's latest, sorry.  
>>> I've listed the primary ones below.
>>>
>>> (1) The iso 639 code link was broken, so I revised it.
>>> (2) Figure 1 needed to be moved down two paragraphs and the reference 
>>> to it moved accordingly, in order for the current text to make sense.
>>> (3) The "DE Distribution Tags" subheading was lost, it was appearing 
>>> as just regular text, so I fixed that.
>>> (4) (There is still a formatting problem with pages 11/12, which I 
>>> didn't fix.)
>>> (5) Some of the http://... links were not links, so I made them links.
>>> (6) This version still has the DE schema in Appendix A, which I 
>>> prefer. I agree with Mary that normally and traditionally and from a 
>>> data management view, one would just link to the schema; however, for 
>>> adoption and educational purposes especially from a printout that one 
>>> could read on a train or wherever, it's useful to have it with the 
>>> paper.   I also was making another point by including it as Appendix 
>>> A.  The point is that the DE is simple, it's only 3 pages, and in 
>>> fact, it's so simple I can include it as an Appendix right here for 
>>> the reader's convenience in a printout. I also liked the idea of 
>>> handing the paper to someone and having it be complete and 
>>> stand-alone. The power of being able to hold something in your hand 
>>> is still valuable. When I show the paper to someone, I will flip to 
>>> the back and point at things. It's useful to have the schema there in 
>>> the printout for these instantaneous educational and tutorial 
>>> purposes without having to take the time to go look it up.  So my 
>>> preference would be to leave it in. My suggestion is that we have 
>>> both an official link (that won't change) to the schema referenced in 
>>> the paper, but also include the schema in the Appendix as an 
>>> unofficial convenience. (When a new version of the schema comes out, 
>>> a new version of the paper will also need to come out, and there will 
>>> be no confusion which schema the old paper was referencing because 
>>> it's right there in the Appendix.)
>>>
>>> --Jeff
>>> 619-208-3018
>>>
>>> ________________________________
>>>
>>> From: Rex Brooks [mailto:rexb@starbourne.com]
>>> Sent: Sat 7/25/2009 9:31 AM
>>> To: Waters, Jeff CIV SPAWAR SSC PAC, 53621
>>> Cc: Dee Schur; carol.geyer@oasis-open.org; mary.mcrae@oasis-open.org; 
>>> dellis@sandia.gov
>>> Subject: Re:
>>>
>>>
>>>
>>> Thanks Jeff, Hi Dee, Carol, Mary, Dave,
>>>
>>> I deleted the old stylesheet which was a mix of the stylesheet you have
>>> on your machine, Jeff,  and selections from the OASIS Specification
>>> Template which I originally advised, and replaced it with the OASIS
>>> Specification Template and adjusted the styling throughout, which
>>> brought the total number pages down from 18 to 14. I put the two
>>> Figures, the Schema and Example into the "code" format which I think
>>> sets it off better.
>>>
>>> Carol, Dee, Mary, this is not a White Paper per se even though it
>>> addresses some of the things a White Paper does. I am putting it into
>>> the White Paper Template, too, and I will send it to you when I'm done.
>>> However, we want to get the feedback process started and we need to be
>>> clear that our approach doesn't fall neatly into a White Paper category.
>>> We also want to get this out as soon as we can, with the caveats I
>>> suggest at the end of this too-long message.
>>>
>>> Background: We are in the midst of defining a set of document and
>>> documentation types plotted against target vendor and governmental
>>> audiences for each specification at beginning, intermediate, and
>>> advanced levels. Further differentiations are being worked for
>>> non-technical managers, technical staff, and decision makers, and there
>>> will be further refinements.
>>>
>>> In the EM Adoption TC's Collateral and Documents SC, which I'm chairing,
>>> we are developing a spreadsheet that plots document types against
>>> audience types, so that we can keep track of our thinking and create the
>>> framework for documenting our progress and providing accountability. We
>>> want to learn from our experience in a structured way.
>>>
>>> We are coordinating with the EDXL-RIM (Reference Information Model) SC
>>> for its immediate need for a similar Basic or Welcome document, as well
>>> as the next level up, an intermediate technical audience.
>>>
>>> We think each of these audience groups need to be addressed in different
>>> ways for different purposes. Needless to say, we are only at the
>>> beginning, and this is the first time we've done this, so we wanted to
>>> get to a point where it makes sense to ask you for your feedback, and
>>> that is what we need from you as soon as you can get to it.
>>>
>>> We actually have enough people working on these projects to make decent
>>> progress. What I think we need to do is to develop an identifiable look
>>> and feel for the format and a tone for the writing for each of these
>>> levels and avoid the kitchen-sink syndrome where we try to address all
>>> audiences at all levels simultaneously. Of course, then the task will be
>>> to get the appropriate documents to the correct audience.
>>>
>>> As I said, I am putting this document into the White Paper format so
>>> that we can compare and think about the distinctions we want to make. I
>>> really like the White Paper format as a former art director-designer,
>>> but I worry that a technical audience might not know what to do with it,
>>> e.g. how to interpret it, as in "Is this addressed to me?"
>>>
>>> Dave, Jeff has cast the issue of the lack of complete DE-aware
>>> distribution in the last sentence of the first paragraph of Section 6:
>>> "There are a number of current distribution mechanisms available while
>>> fully DE-aware solutions are emerging." Remember, we are trying to focus
>>> on what can be done now and staying as positive as we can. Making
>>> negative statements like, "Fully DE-aware solutions are not yet
>>> available," will tend to discourage rather than encourage our audience.
>>>
>>> Further, in the last paragraph, Jeff writes: "Of course, these options
>>> are only the beginning..." and while I don't want to lead our audience
>>> into thinking they can achieve everything in the DE now, we have to
>>> build adoption and demand for that now.
>>>
>>> However, having said that, I think we really need to get a second,
>>> intermediate level document underway soon, perhaps working with Gary Ham
>>> and DM OPEN. At the same time we should make sure that DM OPEN is clear
>>> with anyone we channel to them that this whole system is being
>>> overhauled and full implementation efforts should be coordinated with
>>> their timeline. Otherwise, everyone we send their way will come away
>>> with a really bad impression when that system is changed in such a way
>>> that it will not be backward compatible, and that is exactly what
>>> they're doing.
>>>
>>> We have to very careful with this.
>>>
>>> Cheers,
>>> Rex
>>>
>>> Waters, Jeff CIV SPAWAR SSC PAC, 53621 wrote:
>>>       
>>>> Hi, Rex:
>>>>
>>>>  Sorry this took me awhile to send to you.  I didn't yet join the 
>>>> infrastructure subcommittee, so perhaps you could upload these 
>>>> documents to the resources folder for me. Also I wanted to give you 
>>>> another chance to look at the changes I made to last paragraph of 
>>>> Section 6 before uploading. If you don't agree with what I did, 
>>>> please change back to wording you used or otherwise as you see fit.
>>>>
>>>>  I'm cc'ing Dee, so she'll know that basically (after your review 
>>>> and upload), it may be ready to vote this draft out of the 
>>>> infrastructure subcommittee. Thanks.
>>>>
>>>> --Jeff
>>>>
>>>> P.S. I wanted to revise the last paragraph of Section 6 to ensure we 
>>>> include Dave's concern that people realize that routing solutions 
>>>> which will take full advantage of the DE have yet to be developed. I 
>>>> tried to say this in a positive way. Also I wanted to note that 
>>>> additional papers explaining EDXL will be forthcoming, but to do so 
>>>> in a positive way without implying that people need to wait before 
>>>> proceeding to adopt.  I added your wording to the excel spreadsheet 
>>>> and also the wording I revised and why.  On the other hand, if you 
>>>> don't like what I did, you can change back.
>>>>
>>>> Your wording was:
>>>>
>>>> "Please be aware that this is a basic introduction to a necessarily 
>>>> technical topic and is aimed at an audience with a managerial level 
>>>> understanding of the technical issues involved. It is not intended 
>>>> to be a comprehensive technical manual. An intermediate technical 
>>>> level paper is planned to which managers can refer their technical 
>>>> staff  for guidance in getting started on implementing EDXL-DE in 
>>>> order to distribute the various emergency communications message 
>>>> payloadss for which EDXL-DE is intended."
>>>>
>>>> My thoughts and revision:
>>>>
>>>> I may be wrong, but I'm not sure this paragraph is necessary. The 
>>>> title and many parts of paper refer to this as a "basic" intro, and 
>>>> I think it's clear that it is not a comprehensive technical manual. 
>>>> Although basic, I'm not sure I agree that it is directed toward 
>>>> managers, since I don't think managers are interested in the xml 
>>>> examples. Also I'm afraid this paragraph might suggest to readers 
>>>> that they should wait until the next paper comes out before 
>>>> proceeding.  It is important to note that the routing solutions 
>>>> proposed are not complete and don't take full advantage of the DE. 
>>>> Also important to note that other explanatory papers are in the 
>>>> offing. So suggest revising to rephrase main points in a more 
>>>> positive light.  Section 6 last paragraph to read: "Of course, these 
>>>> options are only the beginning. New routing solutions and 
>>>> architectures are needed to take full advantage of the DE. Now is a 
>>>> good time to consider joining OASIS so your company or organization 
>>>> can assist in these efforts." Also added this line to the end of 1st 
>>>> paragraph of Section 7 Conclusion: "Additional papers explaining the 
>>>> details of the EDXL standards are underway."
>>>>
>>>>         
>>> -- 
>>> Rex Brooks
>>> President, CEO
>>> Starbourne Communications Design
>>> GeoAddress: 1361-A Addison
>>> Berkeley, CA 94702
>>> Tel: 510-898-0670
>>>
>>>
>>>
>>> <EDXL-DE-Basics-WD05[1]-JeffFixes.doc>
>>>       
>>
>>     
>
>
>   


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