[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency] RE: EDXL-DE 2.0 for the F2F - Objectivity, Subjectivityand Interpretation.
I concur. Cheers, Rex Carl Reed wrote: > Not to stir the pot, but if nay (minor) changes are made to the > definition of the circle element, would be nice to at least structure > the content to be consistent with the PIDF-LO definition so that CAP > and EDXL 2.0s are aligned with NENA Next Generation 911 specification > of the use the Location Object. > To whit: > > The circular area is used for coordinates in two-dimensional CRSs to > describe uncertainty about a point. The definition is based on the > one-dimensional geometry in GML, gml:CircleByCenterPoint. > > The centre point of a circular area shall be specified using a two > dimensional CRS; in three dimensions, the orientation of the circle > cannot be specified correctly using this representation. A point with > uncertainty that is specified in three dimensions SHOULD use the > Sphere shape type. > > <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326" > xmlns:gs="http://www.opengis.net/pidflo/1.0" > xmlns:gml="http://www.opengis.net/gml"> > <gml:pos> > 42.5463 -73.2512 > </gml:pos> > <gml:radius uom="urn:ogc:def:uom:EPSG::9001"> > 850.24 > </gml:radius> > </gs:Circle> > The only change I would recommend would be to use an http URI for the > CRS and uom definitions. Anyway, please note the lat-long order and > the use of white space. GML uses white space. > Also, FYI, this schema snippet for circle is almost identical to what > the schema will look like in the GML OASIS where document. > Cheers > Carl > > ----- Original Message ----- > *From:* McGarry, Donald P. <mailto:dmcgarry@mitre.org> > *To:* Gilmore, Timothy <mailto:TIMOTHY.D.GILMORE@saic.com> ; > emergency@lists.oasis-open.org > <mailto:emergency@lists.oasis-open.org> > *Sent:* Thursday, June 24, 2010 3:54 AM > *Subject:* [emergency] RE: EDXL-DE 2.0 for the F2F - Objectivity, > Subjectivity and Interpretation. > > Tim- > > I wholeheartedly agree! > > I did bring this up for discussion earlier and we agreed that a > circle /should/ be > > <circle>lat’,’lon<space>radius</circle> > > Which makes comment 1 and the example wrong (extra space in both > between the lat and lon). > > This is on the issues list for 2.0. I will add the point about the > radius, because as stated it should be an *unsigned* integer with > a maximum value less than that of a normal signed or unsigned int. > > Are you suggesting that we use different wording for the OPTIONAL, > MAY use multiple? That was a little confusing to me at first, so > input would be appreciated. > > I have added these topics to the issues list > > -Don > > Office: 315-838-2669 > > Cell: 703-595-9375 > > dmcgarry@mitre.org <mailto:dmcgarry@mitre.org> > > *From:* Gilmore, Timothy [mailto:TIMOTHY.D.GILMORE@saic.com] > *Sent:* Wednesday, June 23, 2010 10:24 AM > *To:* emergency@lists.oasis-open.org > *Subject:* [emergency] EDXL-DE 2.0 for the F2F - Objectivity, > Subjectivity and Interpretation. > > All, > > Some of the things we look at are objectivity and subjectivity due > to our accreditation under the American Association for Laboratory > Accreditation (A2LA) for NIMS STEP and IPAWS Conformity Assessment > (CA) testing. Many elements under the OASIS EDXL suite of > standards including CAP use words such as “SHOULD” and “MAY” which > are clearly subjective in nature. One of our engineers pointed out > some issues that we should keep in mind when going over the > EDXL-DE 2.0 document during the F2F. > > For CAP: > > /What we're looking for are rules or constraints that are open to > interpretation, or not fully specified, rather than being > completely "nailed down."/ > > / / > > /For example, consider the <circle> element. Is the following a > "correct" <circle> element?/ > > / / > > / <circle> 0, 0, 150000000 </circle>/ > > / / > > /It certainly fits the descriptions in that element's comments: > (1) it's in the form "latitude, longitude, radius"; (2) the > central point conforms to WSG84; (3) the radius value is expressed > in kilometers; and/ > > /(4) it is a properly escaped XML string./ > > / / > > /Then again, the radius of the circle is approximately the > distance between the Earth and the Sun. Note that the given > definition includes the word "geographic" (twice!) and that the > center of the circle is specified as longitude and latitude, all > of which indicates to me that the circle ought be to Earth-bound. > Someone else may interpret the standard differently, and the > standard doesn't put a real limit on the radius of the circle./ > > / / > > /The point is that the standard doesn't really specify enough for > a tester to determine whether or not a <circle> element is > conforming./ > > /The tester has to make up his (or her!) own rules to complete the > test./ > > /Multiple testers will certainly come to different conclusions, > and all will be correct to within the subjectivity allowed by the > standard./ > > / / > > /(And that all said, note that the given example doesn't match the > form given in comment 1; the comma between the longitude and the > radius is missing. Since all of section 3 of this standard is > normative, this is a bug in this standard.)/ > > / / > > /For another example, consider the <senderRole> element. The > standard says "OPTIONAL, MAY use multiple." Despite the words > "OPTIONAL" and "MAY," an individual tester can determine without a > doubt whether a given message contains zero or more <senderRole> > elements, and an infinite number of testers (all else being equal) > will come to exactly the same conclusion./ > > Perhaps something to think about at the F2F. > > Thanks, > > *Timothy D. Gilmore* | SAIC > > Sr. Test Engineer | ILPSG | NIMS Support Center | > > IPAWS CA / NIMS STEP > > phone: 606.274.2063 | fax: 606.274.2025 > > mobile: 606.219.7882 | email: gilmoret@us.saic.com > <mailto:gilmoret@us.saic.com> > > P Please consider the environment before printing this email. > -- 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]