kmlchemist / kml-schema

Automatically exported from code.google.com/p/kml-schema
0 stars 0 forks source link

Facilitate third-party extensions of enum types (code lists) #8

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Enumerated types cannot be extended in XML Schema, but perhaps some enum types 
in KML 2.3 should be open to extension (e.g. altitudeMode). That is, they 
should be properly regarded as code lists.

NOTE: Simply declaring an element of type xs:string and defining Schematron 
assertions to detect illegal values is one flexible way to do this, but it 
requires an additional validation step using a rule-based grammar.

Several approaches are considered in this developerWorks article: "Extend 
enumerated lists in XML schema" 
<http://www.ibm.com/developerworks/library/x-extenum/>

Solution 5 (union with string) is quite commonly employed. However, this 
approach requires ad hoc validation which defeats the purpose of defining a 
standard enum type in the first place--the string member effectively "hides" 
the enum values.

Here's a way to introduce a supplementary enum type that is used exclusively 
with some base enum type. We'll use altitudeMode as an example but it applies 
to any enum type that should be open to extension.

1. Define an element group with a choice compositor. One of the particles is 
the standard enum; the other is an abstract (simple) element that provides an 
extension point.

<group name="altitudeModeGroup">
  <choice>
    <element ref="kml:altitudeMode" />
    <element ref="kml:extendedAltitudeMode" />
  </choice>
</group>
<element name="altitudeMode" type="kml:StandardAltitudeModeEnumType" 
default="clampToGround"/> 
<element name="extendedAltitudeMode" type="anySimpleType" abstract="true" />

2. Define a new enum type in some application schema and declare the 
appropriate substitution group affiliation (see attached schema: ns1.xsd)

All values are subject to XML Schema validation using this approach, but it's a 
bit fiddly. KML consumers that don't recognize the custom value will apply the 
standard default value instead.

EXAMPLES

<kml:Point>
  <kml:altitudeMode>relativeToGround</kml:altitudeMode>
  <kml:coordinates>-118.3117,33.3365,6.3859</kml:coordinates>
</kml:Point>

<kml:Point xmlns:ns1="http://example.org/ns1">
  <ns1:altitudeMode>beta</ns1:altitudeMode>
  <kml:coordinates>-118.3117,33.3365,6.3859</kml:coordinates>
</kml:Point>

Original issue reported on code.google.com by rjmart...@gmail.com on 29 Aug 2014 at 3:57

Attachments:

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Here's an alternative approach that eliminates the group definition and relies 
exclusively on element substitution:

<element name="abstractAltitudeMode" abstract="true" 
type="kml:AltitudeModeBaseType"/>
<simpleType name="AltitudeModeBaseType">
  <restriction base="string" />
</simpleType>

<element name="altitudeMode" type="kml:StandardAltitudeModeEnumType" 
default="clampToGround" substitutionGroup="kml:abstractAltitudeMode"/>
<simpleType name="StandardAltitudeModeEnumType">
  <restriction base="kml:AltitudeModeBaseType">
    <enumeration value="clampToGround"/>
    <enumeration value="relativeToGround"/>
    <enumeration value="absolute"/>
    <enumeration value="clampToSeaFloor"/>
    <enumeration value="relativeToSeaFloor"/>
  </restriction>
</simpleType>

See ns1a.xsd for the amended application schema that declares additional 
values. Note that in all cases the enum types derive from 
kml:AltitudeModeBaseType.

Original comment by rjmart...@gmail.com on 2 Sep 2014 at 5:54

Attachments: