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:
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.
(315) 838-2669 Office
(703) 595-9375 Cell
