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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

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


Subject: RE: [emergency] Handling Default ValueLists


Right you are.

R


From: Doug Allport [mailto:doug@allportgroup.com]
Sent: Mon 11/29/2010 3:59 PM
To: Ron Lake; 'McGarry, Donald P.'; 'Lee Tincher'; emergency@lists.oasis-open.org
Subject: RE: [emergency] Handling Default ValueLists

Please note that many of the items associated with CAP-CP in the links are not on the CAP-CP event list. The CAP-CP list is limited to hazardous event types, civil disruptions and public services. I believe the list Ron has referenced as CAP-CP is our Emergency Management Symbology (EMS) list.

 

Cheers,

 

Doug Allport

Allport Group Inc, Doug@AllportGroup.com

Executive Director, Canadian Association for Public Alerting and Notification (www.CAPAN.ca), Doug.Allport@CAPAN.ca

(613) 271-1040 Tel

(613) 294-4425 BlackBerry

 

 

 

From: Ron Lake [mailto:rlake@galdosinc.com]
Sent: November-29-10 2:35 PM
To: McGarry, Donald P.; Lee Tincher; emergency@lists.oasis-open.org
Subject: RE: [emergency] Handling Default ValueLists

 

Hi,

 

These are not in the schema per se.  For example, CityGML and AIXM (two GML Application Schemas) both define large numbers of enumerations.  In CityGML, for example, rather than define these enumerations in the schema, they are defined using GML Dictionaries.  This implementation is currently informative in the specification and will likely stay that way.  Other code lists are defined simply as tables.

 

The idea is then to implement these code lists in a registry.   You can see some examples at:

 

For CityGML:

 

CityGML [1] Building Function Code list (HTML):

http://indicio.wrs.galdosinc.com/reg/query?request=GetRecordById&include=all&ElementSetName=full&view=urn:x-indicio:csw-ebrim:def:registry:transformation:RegistryBrowser&id=urn:ogc:def:citygml:code-list:buildingfunctiontype

 

CityGML [1] Building Function Code list (XML):

http://indicio.wrs.galdosinc.com/reg/query?request=GetRecordById&include=all&ElementSetName=full&id=urn:ogc:def:citygml:code-list:buildingfunctiontype

 

-------------------------------------------------------------

For CAP-CP (Canadian Profile of CAP):

 

CAP CP [2] Code list (HTML):

http://indicio.wrs.galdosinc.com/reg/query?request=GetRecordById&include=all&ElementSetName=full&view=urn:x-indicio:csw-ebrim:def:registry:transformation:RegistryBrowser&id=urn:x-cap-cp:def:scheme:ems-1.0

 

CAP CP [2] Code list (XML):

http://indicio.wrs.galdosinc.com/reg/query?request=GetRecordById&include=all&ElementSetName=full&id=urn:x-cap-cp:def:scheme:ems-1.0

 

 

Note that the HTML is generated on the fly by the registry.


Ron

 

References:

 

[1] OGC CityGML

http://www.opengeospatial.org/standards/citygml

 

[2] CAP CP = Common Alerting Protocol, Canadian Profile:

http://capan.ca/index.php/en/cap-cp/

 

 

From: McGarry, Donald P. [mailto:dmcgarry@mitre.org]
Sent: November-26-10 5:25 AM
To: Ron Lake; Lee Tincher; emergency@lists.oasis-open.org
Subject: RE: [emergency] Handling Default ValueLists

 

Ron-

Could you point me at an example schema that does this?

Thanks!

-Don

Office: 315-838-2669

Cell: 703-595-9375

dmcgarry@mitre.org

 

From: Ron Lake [mailto:rlake@galdosinc.com]
Sent: Wednesday, November 24, 2010 4:11 PM
To: McGarry, Donald P.; Lee Tincher; emergency@lists.oasis-open.org
Subject: RE: [emergency] Handling Default ValueLists

 

Hi,

 

The way that “value lists” are starting to be handled in GML communities (e.g. AIXM, CityGML etc) is to use a registry as part of the specification.  This holds the value list, is subject to specific access control rules, but can be extended without re-writing the specification.

 

Cheers


Ron

 

From: McGarry, Donald P. [mailto:dmcgarry@mitre.org]
Sent: November-24-10 6:12 AM
To: Lee Tincher; emergency@lists.oasis-open.org
Subject: RE: [emergency] Handling Default ValueLists

 

I agree…I forgot to mention this in my note, but I am of the opinion that “IF we can enforce it in the schema we SHOULD”

 

-Don

Office: 315-838-2669

Cell: 703-595-9375

dmcgarry@mitre.org

 

From: Lee Tincher [mailto:ltincher@evotecinc.com]
Sent: Wednesday, November 24, 2010 8:53 AM
To: McGarry, Donald P.; emergency@lists.oasis-open.org
Subject: RE: [emergency] Handling Default ValueLists

 

My 2 cents:  In order to “tightly bind a standard” I believe we should lean toward Option 2.   We have seen abuse of the more open options in things like <parameter> in CAP and it has caused a great deal of confusion in the community….so even though Option 2 does add to the complexity I think the pay-off of tightly defining the usage is well worth it….

 

Thanks,

Lee

 

Those who cannot hear an angry shout may strain to hear a whisper - Leonard Nimoy

 

From: McGarry, Donald P. [mailto:dmcgarry@mitre.org]
Sent: Wednesday, November 24, 2010 8:41 AM
To: emergency@lists.oasis-open.org
Subject: [emergency] Handling Default ValueLists

 

All-

I spent some time this morning trying to figure out how to “do” default valuelists in our schemas.  It seems like there are two options that I could figure out and we need to make a decision as a TC how to approach this…

 

What we “want” to do is to have a ValueList type in a schema and assign default values to it.

Take “DistributionType” in DE 2.0 as an example…

You can do 1 or 2:

1.       Use your own ValueList

2.       Use the default ValueList

a.       A default ValueListURI is declared

b.      An enumeration is declared that is binded to that ValueListURI with the values you can choose from

The problem is that the mechanism to do defaults and restrictions in schemas will allow you to create a restriction on the valuelist type that will default the ValueListURI, but not have a default enumeration, only a value, this doesn’t allow you to do #1.  The other problem is that with a default URI and a  don’t strongly bind to other another…i.e. I can choose the

 

Option 1: Just define default valuelists in an xml file that we include with the schema & define the default ValueListURI to match the xml file URI and keep the “Values” types as string

Pros:

         Doesn’t add more complexity to schema

         Developers can just parse the file and use it

         In some ways more simple (if you ignore the cons)

Cons:

         Not strongly typed – i.e. someone can use the default ValueListURI and put invalid values in

         Not enforced in the schema – i.e. if someone does do the bullet above, it will validate to the schema

         Requires an additional file to be distributed with the schema

         Requires additional and very specific documentation

         A new “concept”

         Requires someone to actually read the documentation ;-)

 

Option 2: Define the default valuelist as a strongly typed restriction on the ValueList type, add a choice or abstraction to the schema for elements with a default ValueList that allows for developers to either use the default or their own valuelist

Pros:

         Strongly typed

         Enforced in the schema

         Default values will be read in with the schema

         Single-file solution

         Matches how KML/GML seem to do things

         Re-uses existing schema concepts

         Doesn’t require “conformance” / “business rule” documentation

Cons:

         More complexity in the schema

         Adds a choice or a layer of abstraction

         Could be considered more complicated on the surface

 

Thoughts?

 

 

 

Don McGarry
The MITRE Corp.
dmcgarry@mitre.org
(315) 838-2669 Office
(703) 595-9375 Cell

 



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