OASIS Emergency Management TC

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

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

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

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

  
    
  
  
    I lean toward what Ron and OGC do. My thinking has been that by
    publishing the value lists separately in a registry we not only
    provide a default value list, but an example of how to do that as an
    added benefit for the audience. However the details would need to be
    worked out. I confess I haven't thought this through in detail,
    expecting that the time would eventually arrive when it would be
    required, and I think that time has now arrived. However, I have no
    problem with Option 2 for the reasons that Don and Lee mention.

Cheers,
Rex

On 11/24/10 1:11 PM, Ron Lake wrote:
    
4E1D53230994FD45A119B5090DFBF4600250FE80@andalusia.Galdos.local" type="cite">
      
      
      
      

        
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
        

      
    
  

Hi,
We currently have a mechanism to deploy code lists to a registry and then do schema validation against the code list in the registry.  This way you can have control on the registry content AND retain the ability to validate data against those values.  I believe that we should go even further and consider having even the specification document in a registry also, as well as any schemas etc.  We would be willing to stand up such a registry for EM if others will work with us.  
By the way we are still looking for others to join the Public Safety and Security subcommittee for GeoWeb 2011.

Cheers

Ron
From: Rex Brooks [mailto:rex.brooks@ncoic.org]
Sent: November-24-10 5:01 PM
To: Ron Lake
Cc: McGarry, Donald P.; Lee Tincher; emergency@lists.oasis-open.org
Subject: Re: [emergency] Handling Default ValueLists
I lean toward what Ron and OGC do. My thinking has been that by publishing the value lists separately in a registry we not only provide a default value list, but an example of how to do that as an added benefit for the audience. However the details would need to be worked out. I confess I haven't thought this through in detail, expecting that the time would eventually arrive when it would be required, and I think that time has now arrived. However, I have no problem with Option 2 for the reasons that Don and Lee mention.

Cheers,
Rex

On 11/24/10 1:11 PM, Ron Lake wrote: 
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:
Use your own ValueList
Use the default ValueList
A default ValueListURI is declared 
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
 

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

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

Hi all,

Still learning and trying to get up to speed here, so take my comments with a grain of salt :)

1. The concept of a registry is good, and I can see a case being made to have a national register that defines the code tables specific to a country - e.g. the US would have one registry, New Zealand another, Canada their own, etc. Whilst there is often a lot of similarities between these, there are often small tweaks required to different countries and their terminology.

2. I guess that it is up to the software to cache registries/code tables offline in case there is no connectivity during an emergency? I don't think we should be expecting realtime validation against a remote registry/code list during an emergency.

In terms of how it could be provided, I'd actually support making it available via as many means as possible. It shouldn't be limited to just XML, for example. It might be very useful for developers to also have code tables available as JSON via a REST interface, so that web applications can directly access the code tables as a web service (even if just internally between multiple web apps running on the same server).

This is something we've been working on in Sahana Eden, and it is quite capable at publishing the same data via a variety of different formats (just by tweaking the extension on the URL). Conceivably it should be quite easy to implement a registry or code table, and have it returned via XML, JSON, CSV and any other formats desired. Implementation of a new output format is pretty simple, it just requires the creation of a new XSLT stylesheet to define the export format.

So, what we may look at is a means of pulling down the authoritative online source e.g. CAP-CP in XML, and importing that to populate a local registry that can be used without having to poll on server on the internet everytime a CAP-CP message is created or read.

From our perspective, it would be great to package a list of online registries and code tables, and when a new server is activated, to go out and suck down the latest versions online (or even offline from a USB stick) and quickly setup a lot of this data for use in an application.

That said, I can also see the case where it would be useful for an organisation to define their own registry/code table so that it fits within their own business logic - particularly if for internal use only, and the data isn't necessarily going to be used by other orgs. So again, it may come back to the software, and the software administrator may have a deployment choice to make whether they want to use external registries, or whether they want to define and host their own internally.

Cheers Gavin



Sahana Eden

Some additional comments.
Note that enumerations may in some cases really be taxonomies - i.e. values in the enumerated list might be subsequently expanded into value lists of their own. For example, we might have an initial list of incident types like:
                Fire
                Flood
                Explosion
                Earthquake
And then realize that these need to be further refined ("subtyped") into say 
                Fire
                   |-Forest
                   |- House
                Flood
                Explosion
                Earthquake
Hence modeling enumerations as flat hierarchies which can then be easily extended is something to think about.
See additional comments in line with your text...


                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
From: Gavin Treadgold [mailto:gavin.treadgold@gmail.com] On Behalf Of Gavin Treadgold
Sent: November-29-10 2:39 PM
To: emergency Oasis TC lists
Cc: McGarry, Donald P.; Lee Tincher; Ron Lake
Subject: Re: [emergency] Handling Default ValueLists
Hi all,
Still learning and trying to get up to speed here, so take my comments with a grain of salt :)
1. The concept of a registry is good, and I can see a case being made to have a national register that defines the code tables specific to a country - e.g. the US would have one registry, New Zealand another, Canada their own, etc. Whilst there is often a lot of similarities between these, there are often small tweaks required to different countries and their terminology.
[RTL]  This is one of the advantages - one can easily deploy different registries for different environments - but they can also share content.  We do this now in the petroleum sector.
2. I guess that it is up to the software to cache registries/code tables offline in case there is no connectivity during an emergency? I don't think we should be expecting realtime validation against a remote registry/code list during an emergency.
[RTL]  I think there are a variety of strategies.  We have client tools that do validation and which cache code lists as you say.  
In terms of how it could be provided, I'd actually support making it available via as many means as possible. It shouldn't be limited to just XML, for example. It might be very useful for developers to also have code tables available as JSON via a REST interface, so that web applications can directly access the code tables as a web service (even if just internally between multiple web apps running on the same server).
[RTL] Our registry can deliver content in a variety of encodings – but based on a common internal representation.  We have a transformation utility that applies a transformation, the latter associated to the content (and there can be many such associations).  The HTML output in the example provided previously was generated in this fashion. JSON could just as easily be generated in the same manner.  The registry can support a RESTful, POST/GET or SOAP interfaces for data requests.
This is something we've been working on in Sahana Eden, and it is quite capable at publishing the same data via a variety of different formats (just by tweaking the extension on the URL). Conceivably it should be quite easy to implement a registry or code table, and have it returned via XML, JSON, CSV and any other formats desired. Implementation of a new output format is pretty simple, it just requires the creation of a new XSLT stylesheet to define the export format.
So, what we may look at is a means of pulling down the authoritative online source e.g. CAP-CP in XML, and importing that to populate a local registry that can be used without having to poll on server on the internet everytime a CAP-CP message is created or read.
[RTL] We suggest this be based on the OGC CSW-ebRIM standard since this supports classification schemes (enumerations), associations etc etc.  Setting up a mirror should not be difficult.  We can provided automated synchronization of master and slave registries.  This way we can readily obtain the objective of multiple registries with partially mirrored content, supporting multiple formats etc.
From our perspective, it would be great to package a list of online registries and code tables, and when a new server is activated, to go out and suck down the latest versions online (or even offline from a USB stick) and quickly setup a lot of this data for use in an application.
[RTL] Ultimately we might want to have a registry of such registries – again easily done with the CSW-ebRIM – since there are metadata models already for service interfaces (other registries).
That said, I can also see the case where it would be useful for an organisation to define their own registry/code table so that it fits within their own business logic - particularly if for internal use only, and the data isn't necessarily going to be used by other orgs. So again, it may come back to the software, and the software administrator may have a deployment choice to make whether they want to use external registries, or whether they want to define and host their own internally.
Cheers Gavin
Sahana Eden
<http://eden.sahanafoundation.org/>
Sahana Eden S3XRC - how we handle exports in multiple formats <http://eden.sahanafoundation.org/wiki/S3XRC> 
Sahana Eden S3XML On-the-fly Transformation <http://eden.sahanafoundation.org/wiki/S3XRC/S3XML/Transformation>

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