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

I'm not the expert but I've been told that the better way to handle externally managed lists is through the use of substitution groups and code lists. This then enables users of the spec to create subschemas with their code lists which are enforceable using traditional xml validation on their end and yet the xml is generic spec compliant. NIEM does this but I don't think they have defaults.

One perspective on defaults is don't provide them. If there is a substitutable list of something, then the user should be aware there are different options and if the user is going to use a list of values, the user needs to understand which list they are using and what value. It shouldn't just default. Defaults are just shortcuts. If something is important, you shouldn't have a default value. And same issue with default lists. If the list is important, the user should pick it, it shouldn't default. Better to have enforeceable flexibility via substitution groups and give up defaults than to take on the burden of non-xml validation.

Sample code lists could be provided in the distribution zip of the schema with the associated subschemas for those who just need some guidance.

Just some thoughts.


From: McGarry, Donald P. <dmcgarry@mitre.org>
To: Lee Tincher <ltincher@evotecinc.com>; emergency@lists.oasis-open.org <emergency@lists.oasis-open.org>
Sent: Wed Nov 24 06:12:14 2010
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”



Office: 315-838-2669

Cell: 703-595-9375



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….





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



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


·         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)


·         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


·         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


·         More complexity in the schema

·         Adds a choice or a layer of abstraction

·         Could be considered more complicated on the surface






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


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