OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-rim message

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


Subject: Question RE: ValueList principles expressed in edxl-extensions-v1.0-wd01 [SEC=UNCLASSIFIED]


UNCLASSIFIED

Jeff,

 

The edxl-extensions-wd01 document refers to the use of web URLs to specify the unique location of user lists that will be referenced in ValueList (refer section 6.1.2, page 12)

 

Should this principle be applied in other EDXL standards like CAP Profiles?

 

The reason I ask is because in the Australian CAP Profile (CAP-AU) (see http://docs.oasis-open.org/emergency/edxl-cap1.2-au/v1.0/cs01/edxl-cap1.2-au-v1.0-cs01.doc)  we stipulate a preference for Australian CAP users to draw the <eventCode> value that is to be used in a CAP-AU message, from the "Australian All-Hazards Event Code List (AUeventLIST)".  The OASIS CAP-AU Profile states that a specific <valueName> should be used to denote the event code was drawn from the AUeventLIST, as follows: <valueName>urn:oasis:names:tc:emergency:cap:1.2:profile:CAP-AU:1.0:AUeventLIST:2.0</valueName> (see page 20 under <eventCode> Note 1) and Example A). 

 

My reading of the extensions document made me suddenly realise that OASIS do not store the AUeventLIST electronically, so there is no way anyone can find the AUeventLIST:2.0 from that URN.  I am not an XML or CAP practitioner or programmer but I think this is a problem !  Do you agree?

 

This also makes me think that there is probably a User expectation that the AUeventLIST file should be available for download from the URN specified in an OASIS standard, in accordance with the URN in the <eventCode><valueName> (i.e. urn:oasis:names:tc:emergency:cap:1.2:profile:CAP-AU:1.0:AUeventLIST:2.0).

 

After reading the edxl-extensions-wd01 document, I wondered whether we SHOULD refer to the AUeventLIST within a CAP-AU message using the URL where the master AUeventLIST document is actually stored electronically, rather than the current URN value which cannot be located on the internet.  The current AUeventLIST file is stored at https://govshare.gov.au/xmlui/handle/10772/6495 so I am thinking that we should be revising the CAP-AU Profile to replace the URN with the following: <valueName>https://govshare.gov.au/xmlui/handle/10772/6495</valueName> so that global CAP users can find the AUeventLIST when required.

 

If this change is appropriate, then it will also impact the <geocode> lists that are quoted in the Profile as a backup method to define alert areas whenever the consumer system has no ability to interpret the more accurate geospatial information stated in <polygon> or <circle> sub-elements.  The CAP-AU Profile (pages 33-34) provides examples of location reference lists that Users might refer to: Geo-coded National Address File (G-NAF), ISO3166-2, Gazetteer of Australia, and Postcodes.  Each of these lists can be drawn from a specified URL address stated in the <geocode> Notes.  I now think we should quote these URLs in the CAP-AU Profile vice the URN that is currently used in the OASIS document.

 

I would appreciate your feedback on this as soon as possible because the EM-TC is about to vote on a revised CAP-AU CSD03 document next week on July 30.  The CSD03 contains these ambiguities, which should be revised if my logic is correct.

 

 

Regards,

 

Greg Trott 

CAP-AU Custodian for the Australian Government standard for Common Alerting Protocol

Australian Government Attorney-General's Department

 

Download the CAP-AU-STD from www.em.gov.au/CapAuStd

 

 

From: emergency-rim@lists.oasis-open.org [mailto:emergency-rim@lists.oasis-open.org] On Behalf Of Jeff Waters
Sent: Thursday, 25 July 2013 9:20 PM
To: emergency-rim@lists.oasis-open.org
Subject: [emergency-rim] Groups - edxl-extensions-v1.0-wd01.odt uploaded

 

Submitter's message
Please review this Working Draft 01 of the EDXL Extensions document which has been placed in the proper OASIS template and updated with examples using the latest EDXLExtension schema. Thanks.
-- Jeff Waters

Document Name: edxl-extensions-v1.0-wd01.odt


Description
Utilizing the proper OASIS template, this Working Draft 01 EDXL Extensions
provides a basic introduction to the techniques for adding local community
information into existing EDXL standards. EDXL Extensions serve four
important purposes: (1) to allow local communities the flexibility to
incorporate their own needed additional information to support emergency
needs; (2) to provide a structure and process for incorporating additional
information in a manner which enforces reusability and appropriate
information management; (3) to enable communities to explore and document
their emergency terminology; and (4) to serve as a glide-path toward more
formal standardization of emergency information. With EDXL Extensions,
communities can use their own lists of roles or keywords, and their own
user-defined sets of additional terms and values to standards such as
Tracking of Emergency Patients and the EDXL Distribution Element.
Communities can add additional “layers” of business information, such as
Event information, or domain-specific information, such as Earthquake
information, to traditional EDXL messages. The goal is not to replace any
portions of the more standardized EDXL messages, but instead to allow
“extended” information as appropriate to address specific community needs.
This paper describes the two major techniques, ValueLists and the Extension
element, for extending EDXL standards with examples. After reading this
short paper, the reader will be ready to begin using the EDXL Extensions.
Download Latest Revision
Public Download Link


Submitter: Jeff Waters
Group: EM Reference Information Model SC
Folder: Drafts
Date submitted: 2013-07-25 04:20:01

 



If you have received this transmission in error please
notify us immediately by return e-mail and delete all
copies. If this e-mail or any attachments have been sent
to you in error, that error does not constitute waiver
of any confidentiality, privilege or copyright in respect
of information in the e-mail or attachments.




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