[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency-adopt] Re: A few fixes
Hi Rex, This issue has been under discussion in the OASIS Board Process Committee since April of 2007; I am hoping that we can come to a final decision on Wednesday, but am not overly optimistic. Even if the proposal is approved, the existing template will need to be modified to incorporate appropriate notices, etc. Regards, Mary On Jul 27, 2009, at 11:58 PM, Rex Brooks wrote: > 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 > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]