OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-msg message

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