[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [emergency-msg] RE: Rewrite of Section 1.3--Issue 9 (onIssuesList from start)
Sorry for replying to my own message, but since I'm at my best in the morning at about this time, I wanted to keep this discussion in a single thread for now. Having looked back through the Best Practices document, I have to say that I think this should not be used as a normative reference because it is the proposal for the OASIS Profile of GML rather than as a separate approved specification. It was specifically written up for EDXL-HAVE and EDXL-RM, but constructed to be of much wider applicability across OASIS Specifications that require geospatial coordinate systems on a global basis. This is very much a case where a year can really seem longer because I am now recalling discussions we had in the EDXL-RM face-to-face last December, around this issue. My thinking at this point is that, as Alessandro suggests, we need to address geo-oasis:WhereType consistently and at a specification level. I think that it needs to be separate from any given specification, though, so that it can be referenced as a normative included specification, rather than as a section in another domain (or topic) -specific document. Otherwise, I am very uncomfortable with having such an important part of several specifications normatively defined within another specification. One of the reasons why I want to discuss this with Mary and Ram is that I think we are asking for all sorts of trouble down the road if we include it this way. Unforunately, I don't know how we can raise it to approved specification status without having to wait a long time for both OASIS and the Open Geospatial Consortium to approve the profile. Also, BTW, I think most of Alessandro's textual edits are a good improvement on my first draft, but I have quibbles with the structure, which I think should mirror the way that the spec is organized, However, I can live with a more flat than hierarchical section because it reads much better. In any event we can discuss it in our meeting tomorrow. Cheers, Rex At 5:02 AM -0700 9/10/07, Rex Brooks wrote: >Thanks for your review, Alessandro, > >I have invited Carl Reed to our SC meeting >telecon tomorrow to give us his thoughts on >this, and I would appreciate it everyone could >take a look at this issue, I am copying Elysa >with this because it bears on EDXL-HAVE. > >I reviewed the normative and non-normative >sections of EDXL-HAVE and EDXL-RM, and they >treat this differently. EDXL-HAVE cited [OASIS >GML] and I added a non-normative reference to >EDXL-RM which consists solely of a data >dictionary section that I uploaded. I downloaded >the Best Practices document from Carl Reed dated >May 22, 2006 that Sukumar uploaded Oct. 20, >2006. I looked for this document when I found >the data dictionary excerpt that I uploaded, but >forgot that it was a "Best Practices" document, >so I didn't find it at that time last week. This >all directly relates to the issue Alessandro >brought up in the message below. > >What I really think we should do is arrange a >meeting with Mary McRae & Ram Kumar so that we >can consistently address this issue of the >inclusion of other OASIS Standards or proposed >standards, works in progress, Best Practices, >etc, in draft specifications. This also directly >relates to the issue of conformance, too. > >I'd like to get that as settled as we can. > >One issue that strikes me as important is the >inclusion of Best Practices recommendations as >normative. > >The good news is that this is if we include what >we learn in EDXL-RIM as high level reference, we >shouldn't have to revisit this issue for the >next generation of specifications. > >Cheers, >Rex > >At 1:05 AM -0400 9/10/07, Alessandro Triglia wrote: >>I have made a few editorial changes (see the attachment). >> >>*** >> >>Notice the yellow highlight. I have an issue with the normative status of >>the geo-oasis:WhereType (see issue #562 in the issues list). In my view, >>the geo-oasis schema needs to be specified as an integral normative part of >>some OASIS standard (it could be HAVE or RM). Both HAVE and RM seem to >>treat the geo-oasis schema as an external specification but I haven't found >>any referenceable standard that contains it. Perhaps the intent was to >>regard the geo-oasis XSD schema (published on the OASIS website) as a >>normative thing, but I don't think that is acceptable unless it is >>incorporated and completely specified in a standard. (This is the essence >>of issue #562.) >> >>Alessandro >> >>> -----Original Message----- >>> From: Rex Brooks [mailto:rexb@starbourne.com] >>> Sent: Thursday, August 30, 2007 12:56 >>> To: Timothy Grapes; Alessandro Triglia; 'Gary Ham'; >>> Werner.Joerg@ieminc.com >>> Cc: emergency-msg@lists.oasis-open.org >>> Subject: Rewrite of Section 1.3--Issue 9 (on IssuesList from start) >>> >>> Hi Folks, >>> >>> Rather than pick and choose which Issues to add into the next >>> Revision of the Committee Draft-Public Review document, I'm >>> just going to do everything that I can do if there are >>> resolution instructions, so the first relatively major piece >>> of work was Issue 9. I pulled it out of the document in order >>> to send it to you to review. I suggest noting your >>> suggestions and bringing them up in the next meeting (next >>> Tuesday, the day after the Labor Day holiday). >>> >>> I tried to summarize the structure, making sure that all the >>> major elements and their purposes appear in the numbered >>> items with as many of the subelements as seemed to be needed >>> for understanding the scope and the structure, e.g. the way >>> the message elements are organized in Figure 2. >>> >>> The balance between listing everything (too much) and citing >>> only the major elements (too little) is not easy. >>> >>> Have a great holiday, >>> Rex >>> -- >>> Rex Brooks >>> President, CEO >>> Starbourne Communications Design >>> GeoAddress: 1361-A Addison >> > Berkeley, CA 94702 >>> Tel: 510-898-0670 >> >>Attachment converted: Macintosh HD:AT on >>EDXL-RM-Sectio#30D3F3.doc (WDBN/«IC») (0030D3F3) > > >-- >Rex Brooks >President, CEO >Starbourne Communications Design >GeoAddress: 1361-A Addison >Berkeley, CA 94702 >Tel: 510-898-0670 -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-898-0670
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]