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:]
Sent: November-24-10 5:01 PM
To: Ron Lake
Cc: McGarry, Donald P.; Lee Tincher;
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:]
Sent: November-24-10 6:12 AM
To: Lee Tincher;
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
From: Lee Tincher [mailto:]
Sent: Wednesday, November 24, 2010 8:53 AM
To: McGarry, Donald P.;
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:]
Sent: Wednesday, November 24, 2010 8:41 AM
To:
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.
(315) 838-2669 Office
(703) 595-9375 Cell
