OASIS Emergency Management TC

Fwd: [CAP] ASN.1 Formatting?

  • 1.  Fwd: [CAP] ASN.1 Formatting?

    Posted 04-24-2003 14:09
    [Again, sorry for spamming the whole TC... Allen/Rick, any progress 
    on getting the other SC's their lists?]
    
    Quoted below is a note from the CAP Working Group's email list 
    (archive at <http://www.incident.com/pipermail/cap-list/>) about 
    potential benefits of framing CAP in ASN.1 terms.  As I note, I've 
    just recently begun to get oriented to ASN.1, but it seems compatible 
    with our XML focus.  Can anyone offer any insights or comments?
    
    - Art
    
    
    >To: cap-list@incident.com
    >From: Art Botterell <acb@incident.com>
    >Subject: [CAP] ASN.1 Formatting?
    >Date: Thu, 24 Apr 2003 07:08:44 -0700
    >
    >Friends -
    >
    >What appears below is an ASN.1 portrayal of the current (v. 0.7) CAP 
    >message format, generated by running our existing draft XML schema 
    >through an automated conversion tool.
    >
    >From the ASN.1 homepage <http://asn1.elibel.tm.fr/en/index.htm>: 
    >"Abstract Syntax Notation number One (ASN.1) is an international 
    >standard that aims at specifying data used in communication 
    >protocols. It is a powerful and complex language: its features are 
    >designed to describe accurately and efficiently communications 
    >between homogeneous or heterogeneous systems."
    >
    >What's interesting about ASN.1 is that its abstract format with 
    >defined mappings to various real-world encodings, including XML. 
    >What this means is that a message format from ASN.1 can be 
    >translated precisely into XML and also into several specialized 
    >encodings such as the Packed Encoding Rules (PER) "for applications 
    >that undergo restrictions in terms of bandwidth.These encoding rules 
    >describe how the values defined in ASN.1 should be encoded for 
    >transmission ( i.e. , how they can be translated into the bytes 
    >'over the wire' and reverse), regardless of machine, programming 
    >language, or how it is represented in an application program." 
    >(From <http://asn1.elibel.tm.fr/en/introduction/index.htm>.)
    >
    >You'll note below that our current naming convention could be 
    >adjusted for improved ASN.1 compatibility by changing all the 
    >underscores to hyphens.  Some other issues may arise... our friend 
    >Elliot Christian has asked the "asn1xml" working group for their 
    >advice.  Still, the interchange seems to be fairly clean.
    >
    >At this point I'm just getting to know ASN.1 a bit, personally, so 
    >I'm not making any recommendation at this point... but I thought it 
    >might be worth sharing this for discussion.  Anyone else have any 
    >experience, good or bad, with ASN.1?
    >
    >- Art
    >
    >
    >------------------------------------------------------------
    >Generated by xsd2asn1, the XML Schema to ASN.1 translator of France 
    >Telecom R&D
    >
    >Cap-0-7 DEFINITIONS AUTOMATIC TAGS ::=
    >BEGIN
    >
    >IMPORTS
    >   AnyURI, Language, DateTime
    >     FROM XSD;
    >
    >-- CAP Alert Message (draft version 0.7)
    >Alert  ::= -- NAME AS UNCAPITALIZED -- -- NAME AS UNCAPITALIZED -- SEQUENCE {
    >    msg-id -- NAME AS "msg_id" -- UTF8String ,
    >    sender-id -- NAME AS "sender_id" -- UTF8String ,
    >    password UTF8String OPTIONAL,
    >    source-id -- NAME AS "source_id" -- UTF8String OPTIONAL,
    >    sent DateTime ,
    >    msg-status -- NAME AS "msg_status" -- ENUMERATED {actual, exercise, test} ,
    >    msg-scope -- NAME AS "msg_scope" -- ENUMERATED {public, 
    >restricted, private} ,
    >    auth-code -- NAME AS "auth_code" -- UTF8String OPTIONAL,
    >    msg-type -- NAME AS "msg_type" -- ENUMERATED {alert, update, 
    >cancel, ack, error} ,
    >    msg-note -- NAME AS "msg_note" -- UTF8String OPTIONAL,
    >    ref-id -- NAME AS "ref_id" -- SEQUENCE OF UTF8String OPTIONAL,
    >    incident-id -- NAME AS "incident_id" -- SEQUENCE OF UTF8String OPTIONAL,
    >    info -- UNTAGGED -- SEQUENCE OF info -- UNTAGGED -- SEQUENCE {
    >       language Language DEFAULT "en-US" ,
    >       event-cat -- NAME AS "event_cat" -- ENUMERATED {geo, met, 
    >security, rescue, fire, health, env, transport, infra, other, 
    >safety} ,
    >       event-type -- NAME AS "event_type" -- UTF8String ,
    >       urgency ENUMERATED {ongoing, impending, forecast, past, unknown} ,
    >       severity ENUMERATED {extreme, severe, moderate, minor, unknown} ,
    >       certainty ENUMERATED {high, moderate, low, minimal, unknown} ,
    >       audience UTF8String OPTIONAL,
    >       area -- UNTAGGED -- SEQUENCE OF area -- UNTAGGED -- SEQUENCE {
    >          area-desc -- NAME AS "area_desc" -- UTF8String ,
    >          choice -- UNTAGGED -- CHOICE {
    >             polygon SEQUENCE OF UTF8String ,
    >             radius SEQUENCE OF UTF8String ,
    >             geo-code -- NAME AS "geo_code" -- UTF8String } OPTIONAL} ,
    >       target-code -- UNTAGGED -- SEQUENCE OF target-code -- NAME AS 
    >"target_code" -- UTF8String ,
    >       effective DateTime OPTIONAL,
    >       onset DateTime OPTIONAL,
    >       expires DateTime OPTIONAL,
    >       sender-desc -- NAME AS "sender_desc" -- UTF8String OPTIONAL,
    >       headline UTF8String OPTIONAL,
    >       event-desc -- NAME AS "event_desc" -- UTF8String OPTIONAL,
    >       instruction UTF8String OPTIONAL,
    >       info-url -- NAME AS "info_url" -- AnyURI OPTIONAL,
    >       image-url -- NAME AS "image_url" -- AnyURI OPTIONAL,
    >       audio-url -- NAME AS "audio_url" -- AnyURI OPTIONAL,
    >       contact UTF8String OPTIONAL,
    >       parameter -- UNTAGGED -- SEQUENCE OF parameter UTF8String } }
    >END
    >_______________________________________________
    >CAP-list mailing list
    >CAP-list@incident.com
    >http://www.incident.com/mailman/listinfo/cap-list