OASIS Emergency Management TC

 

> -----Original Message-----
> From: Eliot Christian [mailto:echristian@usgs.gov] 
> Sent: Thursday, April 26, 2007 17:41
> To: Elysa Jones; Alessandro Triglia; emergency@lists.oasis-open.org
> Cc: Olivier DUBUISSON; John Larmouth; Carl Reed
> Subject: RE: [emergency] CAP 1.1 Standard and ITU-T Recommendation
> 
> At 04:49 PM 4/26/2007, Elysa Jones wrote:
> >Hi Alessandro, Thanks so much for joining the fray, welcome. 
>  Please see the current list discussion Subject:  CAP 1.1 
> Standard and  ITU-T Recommendation - TC Task 3 (ASN.1) where 
> a lively discussion is underway.
> 
> Olivier and John pointed out that I was not taking into 
> account the ENCODING-CONTROL section at the end of the ASN.1 
> module. This will assure that the values as actually 
> transmitted are the same case as specified in the current standard.


Correct.

I have checked the ASN.1 in X.cap1, and I think it is correct and matches
the XML schema perfectly.

I have a few minor comments on the X.cap1 document.  I will send them
tomorrow morning.  (Is there a special format for sending comments to the
TC?  If not, I will use something similar to the ISO/IEC JTC 1 comment
matrix.)


> 
> With regard to the embedded explanatory text on data element 
> semantics, I certainly agree that neither the XML Schema nor 
> the ASN.1 Specification should be a primary source for this 
> textual material. It should be carried primarily in the data 
> dictionary under the heading "Notes or Value Domain", and the 
> current standard mostly adheres to that practice. However, 
> there there are a couple of notes pertaining to geographic 
> matters that are not in the data dictionary per se, although 
> they are in the standard. (Specifically, "coordinate pair" is 
> defined in 1.5 Terminology; "WGS-84" is described in 3.3.1 
> WGS-84 Note.) The ASN.1 embedded explanatory text can simply 
> refer to those notes as well.


The ASN.1 spec (unlike the XML schema in CAP 1.1) contains many in-line
comments, which may lead to the expectation that those comments are intended
to be complete, but in fact they are not.  They need to be revisited.

Alessandro


> 
> My point about the "polygon coordinates winding order" is 
> also not an issue for the ASN.1, as John noted. I would say 
> it is also not an immediate issue for the standard as it sits 
> at version 1.1. Perhaps the next version of the standard 
> could simply note in the data dictionary entry for the 
> polygon element: "the winding order of coordinates is 
> counter-clockwise".
> 
> Eliot 
> 

Friends -

Sounds like a lot of important details are being picked up here, so  
may I offer a more general suggestion?  Is there someplace where it  
is, or could be, stated explicitly that our overriding intent is for  
the ASN.1 and XML codings to represent the same data structure  
interchangeably?

That might seem trivial or obvious, but there's always the  
possibility that some small inconsistency will slip past our  
collective inspection, however thorough.  Might it be prudent,  
therefore, to memorialize our overall intent as an added safeguard  
against some accidental artifact being mistaken for intentional at  
some point in the future?

- Art

Art Botterell wrote:
> Friends -
> 
> Sounds like a lot of important details are being picked up here, so may 
> I offer a more general suggestion?  Is there someplace where it is, or 
> could be, stated explicitly that our overriding intent is for the ASN.1 
> and XML codings to represent the same data structure interchangeably?

This is already mentioned in ITU-T Rec. X.1303.1 (and there is a note in 
X.1303 that points to X.1303.1 and says the same). Please check if it is 
an answer to your suggestion.

> That might seem trivial or obvious, but there's always the possibility 
> that some small inconsistency will slip past our collective inspection, 
> however thorough.  Might it be prudent, therefore, to memorialize our 
> overall intent as an added safeguard against some accidental artifact 
> being mistaken for intentional at some point in the future?

Well... this would mean that ITU-T Rec. X.694 (Mapping from XSD to 
ASN.1) is broken ;-)
-- 
Olivier DUBUISSON, ITU-T ASN.1 Project leader (including OID)
France Telecom
NSM/RD/DDEV/PST - BP 50702 - 22307 Lannion Cedex - France
tel: +33 2 96 05 38 50 - fax: +33 1 58 15 52 05

On Apr 27, 2007, at 4/27/07 12:06 AM, Olivier DUBUISSON wrote:
> Well... this would mean that ITU-T Rec. X.694 (Mapping from XSD to  
> ASN.1) is broken ;-)

I would never say that... ;-)

- Art

Makes good sense to me.

Regards,
Rex

At 11:29 PM -0700 4/26/07, Art Botterell wrote:
>Friends -
>
>Sounds like a lot of important details are being picked up here, so 
>may I offer a more general suggestion?  Is there someplace where it 
>is, or could be, stated explicitly that our overriding intent is for 
>the ASN.1 and XML codings to represent the same data structure 
>interchangeably?
>
>That might seem trivial or obvious, but there's always the 
>possibility that some small inconsistency will slip past our 
>collective inspection, however thorough.  Might it be prudent, 
>therefore, to memorialize our overall intent as an added safeguard 
>against some accidental artifact being mistaken for intentional at 
>some point in the future?
>
>- Art


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309

Agreed, I'll ask the OASIS Staff about any guidance along these 
lines.  Thanks, Elysa

At 08:20 AM 4/27/2007, Rex Brooks wrote:
>Makes good sense to me.
>
>Regards,
>Rex
>
>At 11:29 PM -0700 4/26/07, Art Botterell wrote:
>>Friends -
>>
>>Sounds like a lot of important details are being picked up here, so 
>>may I offer a more general suggestion?  Is there someplace where it 
>>is, or could be, stated explicitly that our overriding intent is 
>>for the ASN.1 and XML codings to represent the same data structure 
>>interchangeably?
>>
>>That might seem trivial or obvious, but there's always the 
>>possibility that some small inconsistency will slip past our 
>>collective inspection, however thorough.  Might it be prudent, 
>>therefore, to memorialize our overall intent as an added safeguard 
>>against some accidental artifact being mistaken for intentional at 
>>some point in the future?
>>
>>- Art
>
>
>--
>Rex Brooks
>President, CEO
>Starbourne Communications Design
>GeoAddress: 1361-A Addison
>Berkeley, CA 94702
>Tel: 510-849-2309
>

Hi Elysa,

Do we have an update on where things stand?

Cheers,
Rex

At 8:27 AM -0500 4/27/07, Elysa Jones wrote:
>Agreed, I'll ask the OASIS Staff about any guidance along these 
>lines.  Thanks, Elysa
>
>At 08:20 AM 4/27/2007, Rex Brooks wrote:
>>Makes good sense to me.
>>
>>Regards,
>>Rex
>>
>>At 11:29 PM -0700 4/26/07, Art Botterell wrote:
>>>Friends -
>>>
>>>Sounds like a lot of important details are being picked up here, 
>>>so may I offer a more general suggestion?  Is there someplace 
>>>where it is, or could be, stated explicitly that our overriding 
>>>intent is for the ASN.1 and XML codings to represent the same data 
>>>structure interchangeably?
>>>
>>>That might seem trivial or obvious, but there's always the 
>>>possibility that some small inconsistency will slip past our 
>>>collective inspection, however thorough.  Might it be prudent, 
>>>therefore, to memorialize our overall intent as an added safeguard 
>>>against some accidental artifact being mistaken for intentional at 
>>>some point in the future?
>>>
>>>- Art
>>
>>
>>--
>>Rex Brooks
>>President, CEO
>>Starbourne Communications Design
>>GeoAddress: 1361-A Addison
>>Berkeley, CA 94702
>>Tel: 510-849-2309


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309

I will be putting a complete note out to the list soon on our 
summary/status on the three tasks.  We will plan to review the status 
on our call tomorrow.  I am hopeful to have this complete now in time 
to submit to ITU by May 10.  Thanks, Elysa

At 11:51 AM 4/30/2007, Rex Brooks wrote:
>Hi Elysa,
>
>Do we have an update on where things stand?
>
>Cheers,
>Rex
>
>At 8:27 AM -0500 4/27/07, Elysa Jones wrote:
>>Agreed, I'll ask the OASIS Staff about any guidance along these 
>>lines.  Thanks, Elysa
>>
>>At 08:20 AM 4/27/2007, Rex Brooks wrote:
>>>Makes good sense to me.
>>>
>>>Regards,
>>>Rex
>>>
>>>At 11:29 PM -0700 4/26/07, Art Botterell wrote:
>>>>Friends -
>>>>
>>>>Sounds like a lot of important details are being picked up here, 
>>>>so may I offer a more general suggestion?  Is there someplace 
>>>>where it is, or could be, stated explicitly that our overriding 
>>>>intent is for the ASN.1 and XML codings to represent the same 
>>>>data structure interchangeably?
>>>>
>>>>That might seem trivial or obvious, but there's always the 
>>>>possibility that some small inconsistency will slip past our 
>>>>collective inspection, however thorough.  Might it be prudent, 
>>>>therefore, to memorialize our overall intent as an added 
>>>>safeguard against some accidental artifact being mistaken for 
>>>>intentional at some point in the future?
>>>>
>>>>- Art
>>>
>>>
>>>--
>>>Rex Brooks
>>>President, CEO
>>>Starbourne Communications Design
>>>GeoAddress: 1361-A Addison
>>>Berkeley, CA 94702
>>>Tel: 510-849-2309
>
>
>--
>Rex Brooks
>President, CEO
>Starbourne Communications Design
>GeoAddress: 1361-A Addison
>Berkeley, CA 94702
>Tel: 510-849-2309
>

Alessandro Triglia wrote:
> 
> I have checked the ASN.1 in X.cap1, and I think it is correct and matches
> the XML schema perfectly.

I would recommend that everybody gets accustomed to the official 
reference of these 2 new ITU-T Recommendations:
ITU-T Rec. X.1303 for OASIS CAP 1.1 (previously, X.cap, not X.cap1!)
ITU-T Rec. X.1303.1 for the ASN.1 specification for CAP 1.1 (previously, 
X.cap2).

So please use them in any future correspondence.

I'd not like to see things like X.cap and X.cap2 in press releases :-)
-- 
Olivier DUBUISSON, ITU-T ASN.1 Project leader (including OID)
France Telecom
NSM/RD/DDEV/PST - BP 50702 - 22307 Lannion Cedex - France
tel: +33 2 96 05 38 50 - fax: +33 1 58 15 52 05