Re: [emergency] CAP 1.1 Standard and ITU-T Recommendation - TC

[Olivier DUBUISSON <olivier.dubuisson@orange-ftgroup.com>]

Forwarding on behalf of John Larmouth:
-------- Original Message --------
All,

I am pleased that this thread is being actively persude.  I guess 
Olivier will keep me involved wit any further remarks made.  (I am an 
OASIS member, and maybe should take the trouble to join the TC?????)

>>> In the given ASN.1, the values in the enumerated lists are all listed
>>> with initial characters in lower case. The XML version has used upper
>>> case as the initial character. I doubt that ASN.1 really cares about
>>> the capitalization of string values, 

The encoding instructions say that these are to be upper-cased in the 
XML, so there is no problem.

>>> to match the XML string values. (Note that the ASN.1 usage results in
>>> this peculiar-looking value: "cBRNE").

Again, refer to the encoding instructions, where this is changed to the 
XSD value for XML encodings.

>>> I'm feeling that the comments in the "area" element are not quite
>>> as clear as they need to be. In section 1.5 of the standard, there
>>> is a note about the representation of each point with coordinates
>>> given as a comma separated pair of signed decimal degrees in the
>>> order of latitude followed by longitude. Perhaps this definition
>>> of a geographic point as represented by a "lat,lon" coordinate pair
>>> could be copied into the ASN.1. Then, the ASN.1 could describe a
>>> "circle-list" as: "A space-separated list of circles with each circle
>>> defined by the geographic point at its center point, a comma, and the
>>> circle radius; the radius unit being given in kilometers". (As it
>>> stands now, it is not very clear where the spaces and commas belong.)

> I let John Larmouth, Cc'ed to this email, reply to this. I'll forward 
> his answer to this mailing list as he's not subscribed to the list.

We took a decision that the ASN.1 spec should **not** formally define 
things that are not formally defined in the XSD (this stuff is certainly 
not formally defined in the XSD!!), *** although we could have done so 
in several cases ***.

Foe this version, we give nothing more formal than the XSD does, and 
rely on the English text in the body of X.cap1 for the rest (as the XSD 
in X.cap1 does).

It is a weakness of the basic CAP 1.1 that there are things that should 
be formally an enumerated, and formally defined, that are left for the 
informal English text (this also contributes to the - for me - poor 
compression ratio we get from going from XML to binary - 50% is poor, I 
would expect a factor of 4 to 10 if the X.cap1 had been well-designed!) 
  This ought to be corrected in a future revision.  *** But we did not 
want to make any changes to the CAP 1.1 specification ***.  So lots of 
fields are not standardised, and are free-form text, as the ASN.1 spec 
points out.  But this makes binary optimisation very difficult, and we 
did not attempt it.

>>> The description of "altitude" also should note that its unit of measure
>>> is "feet above mean sea level".

I think this is probably worth adding.  But the reference to the CAP 1.1 
clause should surely be enough???  The CAP 1.1 does not say it is "feet 
above mean sea level", although the standard it references probably says 
that.  *** I do not thing that X.cap2 should try to "improve" on X.cap ***.

>>> I would also mention one other comment about "area", particular to
>>> the polygon. We ought to have stated that the "winding order" of points
>>> around the polygon is counter-clockwise. This is difficult for software
>>> to infer, and the inference procedure would be just plain wrong for any
>>> area that extends more than halfway around the Earth, e.g, the Pacific.

Similar comment.  This has nothing to do with X.cap2, and if it is a 
defect inX.cap1, it should be corrected on the Last Call on X.cap1, not 
by a change to X.cap2.

> I have no problem with adding these comments (such changes are editorial 
> and could be handled with no problem on the ITU-T side before the AAP 
> Last Call, or even as comments for one Member-State during the Last Call).

Yes, OK,  but if there are deficiencies in the X.cap1 spec, the comments 
should be on mending that.  ** It is highly inappropriate to clarify 
X.cap1 by added comments in the ASN.1 spec in X.cap2. **

John L

PS  I have too much on at present, and have not checked everything in 
this e-mail in detail, but I believe the above is correct.
-- 
    Prof John Larmouth
    Larmouth T&PDS Ltd
    (Training and Protocol Development Services Ltd)
    1 Blueberry Road
    Bowdon                               j.larmouth@btinternet.com
    Cheshire WA14 3LS
    England
    Tel: +44 161 408 3695		Fax: +44 161 928 8069