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: RE: [emergency-msg] RE: Rewrite of Section 1.3--Issue 9 (on IssuesList from start)


 

> -----Original Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com] 
> Sent: Monday, September 10, 2007 08:41
> To: Rex Brooks; Alessandro Triglia; 'Timothy Grapes'; 'Gary 
> Ham'; Werner.Joerg@ieminc.com
> Cc: emergency-msg@lists.oasis-open.org; 
> creed@opengeospatial.org; ejones@warningsystems.com; 
> Dwarkanath, Sukumar
> Subject: [emergency-msg] RE: Rewrite of Section 1.3--Issue 9 
> (on IssuesList 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.


I think it doesn't have to be in the same **document** as RM or HAVE, but
couldn't it be in a separate document in the same bundle for RM or HAVE,
which we send for public review?  Otherwise we might have to delay both RM
and HAVE until this other specification is approved.


> 
> 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,


I flattened the description because it looked too formal for an
Introduction.  Obviously, it isn't actually formal when you read it, and so
it ends up looking too complicated for its purposes.

Alessandro




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]